Lets say I have a RESTful web api as a backend, and a seperate client side react app. Ideally I'd like that react app to run on android/ios mobile devices. What are my options?
The ones I am already aware of:
Create a "shell" app that is basically a WebView/UIWebView that loads the web app. You could go further and add some other functionality like navigation to make the app feel more native. This would be quick to implement but the downside is the app wouldn't feel as nice as a proper native app.
Use Apache Cordova or similar tool (hybrid app). The advantage over WebView is that it has a standard api/set of plugins to access that allow use of device features like camera or geolocation that work across different platforms.
Just create a completely native app. One option would be to use react-native as this would be a similar developer experience to react, but AFAIK this would still involve the creation of a separate app - existing react code could not be re-used (is this correct?). A great user experience could be provided here but the downside would mean slower development time because another app would need to be created.
Does anyone know if there are any options I've not considered here? Also, any comments on getting some kind of code re-use between react and react-native apps would be great.
Related
I wanted to get a more experienced opinion on something I recently found out. A couple of months ago I set a goal to build myself a mobile app, and the first thing I did was go to developer.android.com and begin reading documentation on how to go about doing this.
I've invested a lot of time in understanding Android Studio and how to make simple apps (and I'm just now getting the hang of it all), but I just recently read about frameworks like PhoneGap(which let web devs who know HTML,CSS, and Javascript make apps too).
Before learning Android, I taught myself web dev through the Odin Project, which taught me a fair amount of HTML, CSS, and Javascript (little iffy on this language, but I'm sure it's something I could pick up easily since I already have a bit of experience).
I'm wondering what you guys feel are the limitations of using these frameworks and whether I should switch over to them, as opposed to continuing with Android since things are beginning to click for me.
Thanks!
I have developed apps for both Android and Phonegap. Phonegap takes advantage of your web development experience and lets you build mobile apps with ease. But it's not a replacement for Android API itself. A good phonegap application requires knowledge about web development and Android API.
However if your aim is to develop an android application, and you are comfortable with web development and Android, I would advice to take Android API.
Phonegap as wonderful as it is for web developers, and startups who can't afford to have dedicated resources for Android, iOS separately, has its limitations.
Performance : Phonegap app's performance is not at par with a native
android application.
Functionality : As one would expect you can't have all the functionality support a native android application has.
Look : You could easily tell apart a phonegap application from a native one. Given phonegap renders all the content in a webview, the look of native ui elements is lost
I think you will always need access to the native API to make good apps.
At least the navigation should be native, so that your app has the look and feel that the user expects, and so that stuff like the back button get correctly handled for you.
Even if there is some plugin that does that for you in a perfect way, I believe it's beneficial to know how Android works.
In the end, frameworks like PhoneGap add a layer inside your app rather than removing one, and it's always better to understand what goes on inside your app.
So the time that you've spent learning native Android won't be lost.
However, it makes sense to use HTML/JS if you want to share code between different platforms.
I think this article from Basecamp shows a very compelling example: https://signalvnoise.com/posts/3743-hybrid-sweet-spot-native-navigation-web-content.
I want to build some kind of multi-user blog that should mainly be used via smartphone but CAN be used at a pc/mac too. I want it to be stored in the iOS and Android AppStores, so just a webapp with mobile-view option doesn't seem right to me. Now my question. Whats the best option to start with? Create the webapp first to get the backend, databases and stuff and than write the native app that gets access to that databases? Or start with native app first and just build a simple webapp that gets access to the native app backend? Or maybe write the webapp with mobile view option and just write a simple native app that uses the UIWebView to show the mobile version of my webbapp? I hope this question is not too confusing^^
P.S. I decided to go for ruby on rails for the webapp and store that stuff on amazon aws ;)
P.S.2 How much is the UI of a native app customizable e.g. TableViews etc? Because implementing WebApp via UIWebView may be the more stylish option?
greetz
Look, Native UI will have quite good performance event on old Android devices,
but it requires some development effort to work with Android SDK. On another had you can create some hybrid webapp using Phonegap, but you shoud keep keep in mind that you may have some performance problems with slow-slow android's web view.
As for me blog app could be implemented with lightweight JS/HTML5, but in this case please don't use Jquery/ jQuery mobile - they are extremly slow, and I experienced huge performance degradation.
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).
Is there any way of developing a mobile app as a self contained Rails/Ruby app?
The idea is to develop in Rails using the normal tools (browser, thin/WEBrick and command line) and then add the Rails app folder to a specially created Android/iOS app, from where it will be compiled to a native executable. This would be similar to the current PhoneGap creation process I guess. I know about RubyMotion but its iOS only, and its not completely Rails anyway.
Does anything like this exist currently?
What would you need to do this? Obviously you need to run a local webserver of some kind.. Do you need to run an entire stack (Apache, Ruby and Rails) inside the native app or could you take shortcuts (like JRuby for Android for example)?
What is your gut feel on how this would perform?
Any thoughts welcome.
EDIT
Gems are probably going to be a BIG issue as well.
Does anything like this exist currently?
Rhodes is in the ballpark, but it is not Rails and (last I checked) cannot use gems. It does, however, have you build so-called hybrid apps using a Rails-ish controller pattern, with partials and all that.
Obviously you need to run a local webserver of some kind
Not necessarily, and it would be an poor idea to do so for security reasons. Hybrid apps, such as Rhodes, have a Web presentation layer (WebView) displaying the HTML content generated by the back-end, without an HTTP stack.
What is your gut feel on how this would perform?
On many devices, I suspect that your app would crash on startup for having run out of memory. On the rest, I would expect mediocre performance, simply because Rails is not particularly svelte.
The strange thing is that you want to use web application as mobile application. Is there a reason to use Rails instead of just Ruby (then you have Ruboto on Android). My opinion that HTML5(+ local storage) is enough to serve mobile part and use API from somewhere on the web.
I am having a browser-oriented web app build on Rails (3.1). I want to make some features of the web app available on mobile devices, too.
Besides...
1.) Building native apps for each vendor of devices and interacting with my rails web app using JSON/XML, ...
I am thinking about reusing as much as business logic already implemented in my rails app by reusing controllers/models and add some new views targeted to mobile devices (in terms of screen size and the like...).
With this approach, I see two alternatives:
2.) Let the end user access the part of the rails app targeted to mobile devices in the mobile browser.
3.) Set up a native mobile app wrapper, e.g. using PhoneGap, and refer to the same part of the rails app used for 2.).
The advantage of 3.) is that I can reuse business logic of my rails web app and having a "phantom" native app for mobile devices at the same time. (I used the term "phantom" because besides the wrapper, it's not really native, this approach actually just mimics a native app.)
Question 1: Are there any other alternatives besides 1.) to 3.) ?
Regarding 3.)
Question 2: Does Apple accept this kind of apps (which fetch large portions remotely) to be uploaded to the app store?
-> I would be surprised if it is so, because it would allow one to change large parts of the app without the notice of Apple.
Question 3: From an architectural/technical point of view, is it recommended to remotely fetch prerenderd html/js to be executed in a "phantom" native mobile app build on top of e.g. PhoneGap?
-> Wouldn't it be better to set up an independent client app within the native mobile app (maybe using backbone.js), keeping all html, css, js locally within the mobile app, and communicate with the backend using JSON/XML or whatever?
I think this is a good question and I've recently come across similar difficulties. I've ended up using (Q3) vaadin with touchkit. Fine if you're doing free but a bit expensive if you're doing commercial (although then you can probably afford it). I realise this doesn't relate to rails but still, I'm assuming the main point of the question was should I build native apps which use web services / middleware or go for pure web apps.
RE (Q2), during my trawl of this current technology, I did read a few articles suggesting that apple are not allowing the web app style. As in, app which simply masks browser window loading remote web app. Essentially, I think where apple are concerned, you'd need to have the functionality tied down to what they agreed to. This doesn't really affect web apps though as you can surely just access them directly from the browser.
RE (Q1), the only alternatives I can see would be different middleware (e.g. MQ, SOAP etc).