I work at a large company that is looking at building apps for internal use only (iPhone/iPad). We are looking for a SIMPLE way of creating apps that essentially are just a web browser with a predefined URL and no address bar/tabs, etc. Essentially a very dumbed down browser with a custom logo. What is the easiest way to accomplish this?
We would obviously be distributing these oursevlves and they wouldn't be available in the App Store, so app guidelines aren't an issue. We are on Windows boxes and are Java/Web developers so we'd rather not get into too much C sharp if at all possible, fyi. Basically it'd be nice if the tool (if one exists), were to allow us to give it a URL, an icon image, and it builds the app from there.
And while we are starting out with Apple devices, we need to be cross platform compliant with whatever tools we use because I can imagine the day when they decide to buy Android or WindowsPhone devices later on.
MobiOne? PhoneGap? Appcelerator Titanium SDK? Can either of these do what we need? Something else?
A big 'No' for MobiOne. I bought it for 99 dollars. As they advertised, I was able to create a static app within hours. But that's pretty much what MobiOne can do. The moment you start using html, javascript or even audio, all sorts of problem seem to creep up. And there is no support in their forums either. My basic question about using the audio player remains unanswered for a month now.
Here is the worst part:
The tool has a poorly built emulator. Often times, my app worked fine in the emulator but failed to run when deployed to a real device. And at times, i have seen the vice versa too.
Since then, I switched over to PhoneGap(which is free). It took me 2 days to just set my environment right. But once I had the environment setup, it took only minutes to deploy my app in to a virtual device.
Looking at your requirement, I would say that your safe bet is PhoneGap.
I don't have a working knowledge in Titanium but I read in a lot of forums that it supports less platforms when compared to PhoneGap. Titanium seems to give a more native feel to the app but that also means you cannot port it to multiple platforms without changing the code.
Apple may reject your app if all it does is wrap a web site in a WebView. You need to have more functionality in your app than just loading a web page.
From the app review guidelines for iOS:
2.12 Apps that are not very useful, are simply web sites bundled as apps, or do not provide any lasting entertainment value may be rejected
You would need to add additional screens to the app like an about page and a contact us page in order for your app not to be rejected.
As you say you know JavaScript, look into appcelerator.com it allows you to build cross platform apps and only writing your code once.
I would re-evaluate your reason for wanting to create these projects as an app in the first place. What app functionality do you want that you don't have now with your web page? You didn't mention anything in your question that would indicate this needs to be an app.
On Apple devices, you could create an icon that points to a web site. You could define the pages in a way that hides the address bar. Lastly, the web pages could easily be cross-platform already.
Wrapping this into an app would just possibly complicate the process. You may need to deploy updated app code to the device, where a refresh in a browser works just as well.
Related
I want to make an home launcher replacement application (e.g Nova Launcer or Go Launcher) using PhoneGap. I've read about PhoneGap plugins but I don't think this feature can be implemented through Plugins.
So is it possible to make a home launcher replacement App?
There's already such a project. You can take a look at this project.
https://github.com/AricwithanA/DOMLauncher
It is a launcher made with phonegap.
The answer to your question is "yes". Phone Gap is just a WebView inside a Java Android project. If something doesn't have a Javascript interface, nor has a Phone Gap plugin yet, you can just make one yourself, or you can just use Java/Android xml directly.
The real problem with using a WebView as a homescreen is that it will really be slow (with no apparent benefit otherwise of loading all the capabilities that normally come with a WebView).
For a project like that to make sense, a cool project you could try doing is to replicate some of the iPhone functionality that's talked about here.
[...]
I expressly endorse this request, as it is not possible to offer a
native-looking WebApp in Android at the time without implementing a
shallow hull of an App, containing just a WebView (or implementing one
of the popular Frameworks like PhoneGap or apparat.io).
This leads to the point where you have to pay 25 USD for offering a
native-looking WebApp on Android. The same thing is free on iOS
devices - and more elegant
In that case, it would actually make sense of using a WebView. Anytime you would have to deal with actual web content, it makes sense to use a WebView because a WebView does a lot of that html rendering/parsing work for you already.
On a side-note, the web site owner I quoted above is slightly wrong about having to pay $25. In Android, he could just have self-signed his own app and distributed it through his web site, although, his main point remains: iOS does do the bookmarking/installing of a web app locally much better than Android, and it would be great if we could get something like that on Android (that could save/install locally the web sites that were especially made for iOS).
I'm thinking about making a mobile game (say something like Wordfeud).
Now I would like to publish this game on Android, iOS, WindowsPhone, facebook and normal browser.
I could go native on all these platforms.
BUT
Since a want it to be a multiplayer game, most of the functionality will be done via a c#.NET webservice with SOAP calls or something.
Now for another project i'm make a mobile website working in WebView (android) and the same website already works in an IOS app.
So.. why not make a jQuery/HTML5/.NET mobile website and some small apps just as a shell to get them in the marketplaces. That way everything will be in one place and updates/bugfixes will be a walk in the park.
What do you think?
Cheers
If you check the Apple Review Guidelines, you could see :
Apps that are not very useful, unique, are simply web sites bundled as Apps, or do not provide any lasting entertainment value may be rejected
You will be able to launch your android one, but you may have your iOS web bundle rejected.
I suggest to have a look to this page before posting to the app store
I think there are a lot of problems with this. If you look at tools that try too help you do this kind of thing, the most powerful ones being Google PlayN and Monkey. There are still a lot of semantic differences between a HTML/Flash/SilverLight game and a Mobile one, The most obvious being differences in input devices and screen resolution sizes.
It's also important to realize that the cost of integrating the different platforms (ie facebook vs. non-facbook, depending on what type of game you're making) may be significant.
Google PlayN: http://code.google.com/p/playn/
Monkey: http://www.monkeycoder.co.nz/
I think that there are 3 things I always see in html5 apps :
-very bad integration to the different platforms
-bad performances, web based is way slower than native.
-nightmare to maintain.
I strongly encourage you to go the native way if you want to do a quality app.
HTML5 is not all wrong. I think it is the right choice if there are big time/budget constraints and/or you don't care about the quality of the app (for exemple if it will be only used internally).
Final thought : why SOAP ?? REST is faster and is not harder to implement.
I have been researching PhoneGap and I'm now at an impasse and need some advice. I know that PhoneGap essentially 'converts' html5,css,JS sites to 'apps' for distribution, which leads me to my question:
Why wouldn't one simply utilize a webview within an activity to do the same thing and keep the app native?
The advantage of PhoneGap is that it provides APIs that enable your HTML/javascript to interact with the phone (e.g. camera, accelerometer, media etc.)
These APIs are standard across multiple devices (iOS, Android, WinPhone, Blackberry etc.). So you can write one set of HTML/javascript and deploy to multiple platforms.
If you just created a WebView you would not have the PhoneGap APIs and you would need to build containers on each platform you were interested in.
Good question I have searched me too, because we went in Phonegap solution and I think it is a wrong way for us.
The long story:
That is very true if you write once a UI with web developer skills than not needed to know native language and it compile, and ready for testing.
Web developers are more so higher the demand => developer price even cheaper.
When the client want a Milestone 1 for his great idea it will ask a few company, freelancers about development price and time. If is a very basic application version with Phonegap you will have the less development cost( off if your web dev skills are the same laver as platform dev skills) with webView at second place and last one the native.
The client is satisfied with app result buit with Phonegap and want to get more investors so it will make a presentation, where they are asking more features.
At Milestone 2 you will add a few features. Some are easy command line install and you get it, some aren't. Maybe you will be unlucky as you want a combination of 2 existing plugin with a few extras. The conclusion will be: you have to develop a plugin. At this point is already a very big sign of interrogation which is cheaper: the Phonegap + Phonegap plugin or a WebView. If you need 5 existing plugin and your has a little modification, than still Phonegap. But if you need only 1 plugin, only yours, than the web view is the proper way. There are also cases which makes the Phonegap stucture useless. Also there is a problem with version control system under Phonegap if you develop web files, and native code too: some are regenerating at each build time some not. Still is expensiver the native platform. Now the required features are developed. The client will make a demo for investors, where will be visible execution speed with this new features. Or here they will require optimisation, runtime speed-up or after publish to market they will see some are running with low end phones and not the ultimate, which ws used at demos and they will decide to go to Milestone 3 : speed up.
At optimisation, speed up (Milestone 3) you will decide as you need native GUI. After all GUI developed with web now you will need to throw out at fence and implement the side, maybe some parts need even NDK to speed up. No way to be good here with Phonegap. But you have hired web developers, or contracted that company. Now go back to that company , developers which can make native code. They will not start from 0, so they need to analyse the code, refactor and your development price will go up at least with 50% as you would start it from 0 with native.
Good Question, you still could use webview for that but you won't be able to access native functions like ringtone, camera, and all that, however, the app done that way will be regarded as a native app.
At our company there is a huge push for cross-platform (iOS and Android) development. Appcelerator Titanium is being considered (and seems to be the only thing that's being considered) to achieve multi-platform development without extra development time.
Everyone here can think of reasons to use Titanium. For reasons against using Titanium I guess the performance of the resulting "native" app from Titanium may not be as good as an app written in Objective-C for iOS. How significant would the difference be? Are there other reasons to not use Titanium (or equivalent)?
Note: I may write Titanium but reasons may not only be Titanium specific only. All reasons in support for coding in platform language (e.g. Objective-C, Java) qualify.
The Good:
Can create iPhone apps using very simple Javascript.
The Bad:
Apple has been rejecting some Titanium apps due to private API calls but Appcelerator hasn't responded to requests for help, nor updated their SDK. http://developer.appcelerator.com/question/123785/app-has-bee-rejected-by-non-public-api
"Native Widgets" are used, but only nominally: there's a layer of
logic and abstraction between them and your code; and this layer
changes their behavior and reduces their speed. The difference is
visible in the Showcase apps.
API docs are perpetually out of date. (no process for refreshing).
A wiki was created, which is becoming out of date. Editing only
allowed for employees.
Github projects do not have wiki enabled.
Appcelerator isn't true open source: they do not accept contributions from the community: The
titanium_mobile project on github has a long list of open pull
requests.
The help forum software has many technical & design weaknesses.
Email notifications from the help forum often do not work.
Staff rarely answers questions in the Q&A forum. Haven't been seen
in months.
Showstoppers appear continuously in "all the little gaps":
Correctly displaying images on the iPhone 4
Correctly loading images in a scrolling list
Although the platform does simultaneously support iOS and android,
the library/framework does not. A lot of runtime testing (if/then's)
is needed in apps that will work on android and iphone.
Continually releasing new products but not fixing existing products
and website problems. The "new" products are announced while in beta
and release candidate phases.
"Chat with Sales" app not attended to.
Appcelerator does not take down outdated training videos.
Stretching the truth and bait-and-switch with pricing: a 30% sale
only applies to yearly memberships, not month-to-month. The blog
posts & marketing materials do not state this. Only upon checkout is
this shown.
[Seen 8/13/2011] Another way in which Q&A forums are broken: The order of
results for a search is trashed: each page of results orders its hits
from oldest to most recent, at the bottom of the page. Go to the next
page of results (i.e. 51-100), and again, the 1-year-old hits are
first, with 6-weeks-old at the bottom.
My Unanswered Questions:
[Seven unanswered Q&A questions not shown: I don't want to be personally identified by Appcelerator staff
and receive sub-par treatment.]
Results:
Am spending many hours trying to discover an API in the absence of documentation, and hacking to discover workarounds. This time is wasted, and would have been better spent simply learning to make apps in XCode & Objective-C.
How significant would the difference be?
AFAIK, Titanium will generate Objective C, so unless their stuff is woefully inefficient, I wouldn't expect speed to be a major issue.
Are there other reasons to not use Titanium (or equivalent)?
Well, that depends on how you define "equivalent".
Personally, when I get into cross-platform apps, I expect that I will use PhoneGap. That's for one reason: standards.
With PhoneGap, you're writing HTML, CSS, and JavaScript, as if you were writing an HTML5 offline app. All PhoneGap does is turn that into an installable package (e.g., APK for Android) and give you opt-in proprietary APIs for getting to device-specific stuff. Their expectation is to simply fill in the "gap" between what HTML5 on mobile supports and what native apps on mobile supports. Heck, it's even in their name. :-)
As a result, what you are writing is the same sort of tech you would use for a Web-based app, and it may even get to share some of the client-side code. You can use whatever you like from mobile frameworks (e.g., Sencha Touch, jQuery Mobile). And, if someday app stores support HTML5 offline apps, you might even be able to drop PhoneGap altogether, if you're not heavily dependent upon the device integration features.
Titanium lets you write in JavaScript, but the standards compliance largely ends there. You're using proprietary APIs for everything, including the whole UI. Personally, I'd rather back a more popular horse -- HTML5 in this case, more so than PhoneGap specifically. If for no other reason, it'll be way easier to hire HTML5-savvy developers than Titanium-savvy developers.
Neither PhoneGap, nor Titanium, nor any of the plethora of other options (e.g., Rhodes, Flash/AIR) give you all of the device capabilities. These engines will vary in their extensibility -- I know that PhoneGap has a plugin model, that Flash/AIR is pretty much only what you get from Adobe, and I'm not sure about any others.
Titanium has one advantage: you get a near-native UI, instead of an HTML-based UI. (I say "near-native" because some of their widgets do not necessarily have native equivalents on all platforms, so they roll their own as needed) For some apps and some audiences, that alone may tilt things in Titanium's favor.
Titanium/iOS specific answer, my 2c.
Native iOS vs Titanium
PROS
It's nearly as fast as native for most things.
The time needed to write a working prototype it's way shorter.
If you need to integrate javascript legacy code or libraries it will work provided that it doesn't use the dom.
Your javascript code needs to be well spaced and to include semicolumns where needed or the compiler will complain and eventually abort the build.
You can use Coffeescript or any other language that compiles to js
Automatic memory management is top notch, getting the same results in objc is always time consuming and sometimes debugging intensive.
You can write your own modules in native code to extend Titanium's capabilities.
It's open source.
They recently changed their support offering removing the 5 app limit, much more affordable.
You can change a view js code while running the app in the simulator, you will see the results when you reload the view you're editing. That's a boon :) (exception: there's no way I know of to reload the code in app.js)
CONS
Debugging is a pain. Haven't tried out Titanium Studio yet, it might be a big improvement.
Adding too many views tends to degrade performance faster than using native code.
The Titanium Developer app on Mac has plenty of interface glitches and you might find yourself restarting it pretty often.
In some versions the print to console debug statements are broken.
You will often stumble into cross-platform abstraction leakage.
Support on the forums is a bit light, many issues you will encounter are not big but still annoying.
Need to pay attention to JSON correctness, the included parser tends to be picky. Using eval is always an option.
Compile times and loading in the simulator are not that fast, titanium objc is pretty big.
Compared to Xcode, Visual Studio & even MonoDevelop, Titanium Studio feels slow (real slow), buggy (restarting several times each day, even reinstalling a few times) and of course you've got to deal with JavaScript... We found that the pain of developing in Titanium was too great, especially when you have competent iPhone & Android devs around so -
We looked long & hard into the best option for cross-platform dev & ended up using Mono - Touch & Droid. It's been great, we do actually share 80% of the code between iPhone & Android, & we're just beginning a port to WP, which is going well (again sharing 80% of the code). Of course it's not a miracle fix - you still need to know how to develop for each platform. I've even grown to like C# almost as much as Obj-C now :-)
Obviously, some will disagree.
I have an app in Android Market which is a standalone app that's essentially a full conduit to an SQLite Database(add, change, delete, inquiry). Some of my potential clients have asked to see a sample of my work, but they don't have an Android device.
Other than just showing them screenshots etc., is there a way I could have them go to a website where they can actually run it & check it out.
I'm thinking there would be a programming element involved (convert app to a mobile website essentially?), hence posted this question here.
Not quite sure where to get started. Any help would be appreciated.
You can use one of the patterns like MVC/MVP/MVVM to create your core library and then develop additional UI variants for different clients: Android, java applet etc.
Alternatively you can develop a mobile web site as you suggested and use simple android app to navigate built-in browser to it. This might be somewhat transparent to most users. I think Android MSN client uses such an approach.
I see 2 relatively easy options.
Give them an .apk designed to only
run on the emulator (you can check
the ID, the emulator ID is 00000...)
and they can boot up an emulator and
run it. If you're worried about them
reverse engineering your .apk you
probably shouldn't go down this
route. Or if you don't want them to
have to install the emulator
Set up a virtual machine and let
your clients remote desktop into it.
Give them permissions to only run
the emulator or however you want to
set it up