(re-post from the PG google group)
I know there's been a lot of conversation on this in the past, but I've been researching it for the past few days and couldn't seem to find a definitive answer (or even what it would entail).
I was wondering how plausible it would be to embed a snapshot build of the Chrome webview (or even the Gecko webview) into a Phonegap app and to use that in place of the native webview that PhoneGap uses. The problem is twofold - 1) Android's native browser/webview is terrible and 2) Each phone seems to have idiosyncratic bugs/differences, which having one set snapshot to build against would fix.
I've seen answers ranging from "Oh, yeah, just build the source and drop it in" to "You'd need a full team of Java devs to hack the PhoneGap API core to get it to work". Does anyone have an answer of what it would entail, how much time it would take, if it's even plausible, etc? I suppose the biggest concern is - given we can get a snapshot build of the Chrome webview, does that break any of the connections to the PhoneGap APIs? Are they tied specifically to the native webview?
Any and all thoughts are appreciated. Thanks!
Chrome has the ability to be embedded by use of the Content Module. In theory (I have never done it) you can build this and embed it into your Application and use that instead of a WebView - it has the advantage of being an up to date Chrome and multi-process. It loses value in that it can't be used pre-Jellybean.
Related
I'm contemplating on using React Native for a new web app. Is it possible to ship both iOS and Android apps using it?
I know that it's on the roadmap, but it's unclear to me whether it's going to be a separate open-source project (e.g., React Android vs React Native), or just one (e.g., React Native).
TLDR: Most likely you can. But it depends on your use cases.
You can aim for about 80~99+% code reuse (depending on how much Android/iOS native views/modules you use eg. Do you have custom graphics code or low-level TCP networking code; Those can only be done in native code; And expose as API to your JS code. The amount of the platform-specific JS code is actually minimal. Plus you can also use platform check like if (Platform.OS === 'android'){} to solve that) of code reuse, which is pretty nice. Dropbox and other companies have done similar projects: using c++ to build a 'shared' component between iOS and Android project, while implementing most of the UI code in native iOS(Objective-c or swift) and Android(java). But now you are doing C++ with Java and Objective-C or Swift, more language to master, more complexity and more brain juice went down the drain. And it probably took some super tough gymnastic move to make different native code work in both iOS and Android, plus debugging...
React Native just makes it a lot easier to write almost everything in JavaScript. But there is a catch, only about 80% of the JS code could be shared. In the foreseeable future, you still need to write 'platform-specific' JS code for Android and iOS versions.
That's why FB said they aim for 'Learn once, code anywhere' instead of 'run' everywhere.
But it's still very nice other than code reuse(80+% code reuse is still a big improvement comparing to maintaining 2 entirely different versions: Android and iOS ya?)
Cmd +R to refresh the app is a GREAT boost for development speed. Waiting for a big project to compile just makes you felt you were dying inside.
Declarative UI you get for free, because of using React. This is another great plus! As you don't need to 'dig' into your specific UI code that often anymore. Data changed? Just 'flush' it and UI just update accordingly. No brain juice wasted.
I just ported my not so complicated Android React Native App to iOS. And it took me 3 days. The request for and iOS version for the App came as a rather abrupt and unplanned move. So could definitely be even faster had I built the Android with a plan for iOS too. Huge win:)
Another great benefit is able to do hot code push without going through the hellish 1 week app store review process. So no more, "YAY, our app is approved. Let's release. Oh Shiiit. Critical bug and our app keeps crashing(that's gonna keep happening for at least a week before your fix is live). And you have to beg Apple to speed up the process". This is possible because the major part of the code base would be written in JS and with tools like AppHub or CodePush, you could almost instantly deploy code to your users. This is conditionally allowed by Apple.
3.3.2 An Application may not download or install executable code. Interpreted code may only be used in an Application if all scripts, code, and interpreters are packaged in the Application and not downloaded. The only exception to the foregoing is scripts and code downloaded and run by Apple's built-in WebKit framework, provided that such scripts and code do not change the primary purpose of the Application by providing features or functionality that are inconsistent with the intended and advertised purpose of the Application as submitted to the App Store.
Lastly, as an open-source project, project longevity tends to be a concern. Not an issue for React Native. Internally used by(FB Ads Manager) and backed by FB(a dozen FB Engineers?) by Facebook, with close to 500 contributors and 25k Stars, React Native is full of life. Seeing is believing :) (https://github.com/facebook/react-native)
EDIT 1
I realized that I am apparently a bit biased and only talked about the good stuff about React Native. So do checkout https://productpains.com/product/react-native/ and Github issues to have a full picture. It's definitely not silver bullet. That being said, it satisfies most of my use case and I couldn't see me use native iOS or Android anytime soon.
EDIT 2
The Facebook F8 conference app released by Facebook (duh..) is 100% open source and they have a really nice tutorial to show you how you could have both iOS and Android native experience(90% as good as native ?), and at the same time, achieved 85% code re-use. check it out --> https://makeitopen.com
EDIT 3
You may also want to checkout Flutter and its pros & cons :)
It doesn't make sense to have a single codebase if you want a truly native experience. At the moment we have things like NavigatorIOS in React Native which provides an iOS-style UI for navigating between app screens, but if we were to just start using that on Android it wouldn't feel like a true Android app.
Therefore I'd expect to see a NavigatorAndroid component or similar when the time comes, and the same for various other components that behave differently between the platforms.
One benefit that you would get is that any application logic - maybe a store, or your backend interactions - could be written in a JavaScript file and then included by both iOS and Android.
So while you won't get that write-once run-everywhere developer experience from React Native I would expect to see a solution that gives first-class UI on both platforms while encouraging as much reuse as possible. I personally also hope to see strong build tools to help develop and ship on multiple platforms.
React Native for Android has just been released, Android folder will be creating along side with iOS folder upon creating a new project.
Just another tip as NavigatorIOS was mentioned. Facebook are not really maintaining the code for NavigatorIOS. Instead they are focusing on Navigator.
Yes. We're running it in production with about 5m registered users.
Some things are a little behind iOS but catching up quickly. It's a good wagon to be on.
React Native is designed so that you can deploy to both iOS and Android. There is a caveat, of course.
React Native has supported iOS for much longer, coming to Android only recently. So, there are some differences in terms of what is supported on each platform.
For example, if you place borders on Text, they will show up on iOS, but not on Android. In order to overcome this, you need to place a View around the Text, and apply a border to that. Luckily, React Native makes it easy to integrate separate stylesheets for each platform (or even platform-specific styling on a single stylesheet).
Support for Android is continuously evolving, so it will only be a matter of time before React Native for Android is on par with iOS. Nevertheless, this shouldn't deter you. In my experience, it's a great way to quickly develop for both platforms, and it does save some headaches.
you don't need to maintenance separate code base for android & ios. Actually you can use same code base for build android & ios. I recommend to read the react-native documentation(according to react-native version you are using) before using any inbuilt component in your code.
Eg:- TextInput component onKeyPress function supports for ios only.
if ur are using external lib check these lib support for both ios and android.
Anyway you have to configure external lib separately(install) both android and ios.
hope this will helpful.
I need to develop a portable application mainly for Windows 8.1 and iPad, but could be expanded for Android, WP and iOS later.
The application consists of calling web services to display data in grids and it contains CRUD operation, and it may save some local data for offline mode then synchronizes later when connectivity is up.
I'm torn between too many solutions, I need your advise for better solution.
1- Solution 1: Go Native for each OS (VS for Windows 8.1 [RT and pro] and xCode for iPad): this solution requires code duplication, logic and UI.
2- HTML5 with WebView app: I think this is a weak solution especially that we have local storage, checking for connectivity and calling ws ...
3- Using Xamarin: I think Xamarin does not support WinRT or Windows 8.1 to share logic code between iPad and Windows 8.1
4- Using Xamarin.Forms: Building the UI is tough and also it does not support Windows 8.1.
From your perspective, what is the best solution? please advices if you have any other proof of concept.
Many Thanks.
Most of the html/hibrid frameworks like Cordova (cordova.apache.org), Ionic (http://ionicframework.com/), etc, uses a native WebView on Android. Until Kitkat the performance of WebView is not production-ready and if you've a list with a lot of elements, the scroll experience is really bad.
If you want to do a simple proof of concept, prototype or whatever, I think that html frameworks are a good alternative. But if you are going to put your bussiness on top of one of this framworks, I would not recommend.
There is an alternative to embed a Chrome using Cordova & crosswalk (https://crosswalk-project.org/documentation/cordova.html) but you will end with an APK ~40Mb for a simple hello world.
Just my 2 cents. I don't see a point in using libraries that are unsupported across the platforms you plan to release and support on. Personally, I'd code natively for each platform. While this takes a lot of work, if you have to ask for direction on which path you want to take your application, then this type of project sounds more like a "you reap what you sow" application. Also, you'll be able to directly support each problem without having to wait for patches, but there are 2 sides to that coin as well. Your opportunity cost is missing future features the library will provide, if it's worth it to you.
If you aim at quality, going native is the only way... You can reduce the amount of work like Google is doing: writing the business logic and unit tests in Java, then converting it to ObjC with J2ObjC and to Javascript with GWT.
In your case, being that Java is a dumbed-down version of C#, you can easily find tools to convert to the latter, finding yourself with native business logic for every platform! That should account for 50%-70% of the codebase...
I think going with HTML5 with webapp view is better option.
Using Cordova (Phonegap) most of the native features are easily achievable in HTML webapp.
PhoneGap Platform Guide
Alot of other plugins are available for the advances features like BLE, NFC.
Calling webservice is really not an issue in HTML5.
Simple ajax is enough, however now a days many advanced frameworks are available which makes your work easy. One of the best among them is Angular JS(maintained by Google ).
Angular JS
For database you can access native database of the target OS or SQLite db of the mobile device.
You can check this link
Storage options
So developing a webapp can be a more efficient solution in your case. It can be best way for you as per my view point. However, you can do some R & D and can find the appropriate for you.
I have a very basic query related to phonegap and android tablet. I donot have the setup currently with me to verify.
I need to know if the development of Android phone and tablet using Phonegap differs, in term of build or any other thing which i should know before starting development
This question is not very descriptive, but I'll throw you a few tips for phonegap development on android:
Develop your layout using chrome/safari.
Make sure your layout is touch friendly and looks good at 320px, 480px, and 768px wide
Don't overdue it on mobile touch frameworks such as "sencha touch". Your app is guaranteed to not feel 100% like a native app and trying to make it feel more native by using one of these can actually have the opposite effect when users start noticing animations being sluggish or buttons and new screens not behaving as normal.
Find an android device to test on that's very mid-grade. Don't make the mistake of using a high end device to test on and seeing smooth javascript/css3 animations only to find out that on the majority of the devices, the android 'WebView' has pretty mediocre performance.
Honestly, it's really not that hard to make an application that has all of the functionality that phonegap offers as a native android app. There are plenty of codesamples and books to help you along the way, great resources (such as SO) to post questions or find answers on. I understand you may want to use phonegap for cross-platform compatibility but if you're looking for 'native feel' and cross-platform compatibility, you may want to look at appcelerator titanium instead. Yes, you'll have to learn their API - but you'll have to learn some of that with phonegap already (and you are still using javascript).
Although I am comfortable with Java, I have much more experience with web development. I am looking to get into programming simple Android games.
Should I just program everything using Javascript/HTML and forget ramping up on Java/Android SDK? I guess my question really is, what are the limitations of PhoneGap? What are some things to consider, etc.?
Some advantages I can think of:
More selection in terms of game engines for HTML5/JS
Faster ramp up time
Automatically deploy to all major platforms
The biggest pro for phonegap is that it takes advantage of your web development experience. I think what most people seem to miss (or ignore) is that there is no advantage in avoiding phonegap for an android only application! You can still write as much native code as you want to, mixing and matching phonegap as you please.
I am writing an Android app that uses text to speech. Because Phonegap doesn't support this in their API, you might think that Phonegap is a bad choice, but actually it was quite easy to call the Java code I need from javascript:
Java code:
public void onCreate(Bundle savedInstanceState) {
//boilerplate and TTS set up
...
this.appView.addJavascriptInterface(this.speak, "speak");
...
}
public void speak(String text) {
this.tts.speak(text, TextToSpeech.QUEUE_FLUSH, null);
}
Javascript code:
speak.say("hello world");
Pros for Phonegap:
deploys to all major mobile devices
sounds like it best fits your skillset
covers most available platform APIs with a uniform code base, no need to learn each one
PhoneGap Build (https://build.phonegap.com/) and Cordova (https://github.com/brianleroux/Cordova) are making it even easier to deploy to multiple platforms
Pros for Android:
Better performance
No limitations on which APIs you can use (i.e., video)
Defined toolset and workflow
native UI components
Fragments API and native layouts make handling different screen sizes easier
It really comes down to whether or not you want to be an Android-only developer or not. That first pro for phonegap is HUGE is you plan to develop for multiple platforms.
I personally have major concerns over PhoneGap apps performance compared to that of a native Android app. The admittedly small amount of testing that I have done makes the PhoneGap version feel very unresponsive compared to native. I don't see how this doesn't translate to a poor user experience. Even PhoneGaps packaged sample application runs poorly.
I was very excited at the possibilities that PhoneGap appeared to open up, but I don't feel like it's there yet. I don't feel comfortable committing to a large project on PhoneGap.
No WAY! Adobe has their cloud build which has a 9.5 MB file size limit. And, they are discontinuing support for other types of build.
I have just spent the past week or so developing a simple Android app using PhoneGap. My great hope was to be able to recommend this product for use in our department as a "write-once, deploy everywhere solution."
In practice, it was more complicated than I would have hoped. I did manage to get an Android version of the app done, but I found a lot of quirks in using basic stuff like getting it to include css and the jquery mobile framework. I kept thinking that this was just my learning curve but a lot of the tutorials I found online were outdated and didn't work in the version I downloaded. The biggest surprise was that you can't link to external documents without using a plugin such as childBrowser, which is a huge drawback.
I tried today to port my app over to iOS and could not get past step one with importing css. I couldn't find any support documentation on this basic step. It's frustrating because this is a simple app that I could craft as native in Xcode in a day or so. It looks like it will take me a lot longer using PhoneGap.
PhoneGap looks really promising, but at the moment I don't want to use it. It's just a question of time. Why would I want to take twice as long on something? It might be a better choice in future versions
Does anybody have experiences from cross platform mobile app development framework MoSync?
It sounds very good and promises much. But does it deliver?
We have used MoSync for 8 months now and I have a good feeling about it. It is still magic to me that you code in C++ and out comes a jar-file or whatever platform you choose.
It is great for application development but I wouldn't recommend it for gaming with advanced graphics. It seems too slow for that on Symbian.
The APIs are very easy and I learned it very fast. And I have the freedom to do whatever components I want thanks to the MAUI framework and using widgets with skins. You can really make an application look very nice.
It is great for me as a developer that I can support so many phones and platforms. I can also do specific behavior and include/exclude functionality based on the phones capabilities.
When it comes to deployment I end up with hundreds of binaries for every device and I have to take care of them my self. To put them on a web server somewhere and make sure that every user get the correct binary when they try to download the app. I wished that they had some kind of app-store so they could host the apps.
MoSync still have a bit to go until it is working properly. There is no guaranty that an application that is build for a specific device actually works on that device. But I'm sure that they will reach there very soon. And when they do... I simply just need to rebuild my app with the SDK (I think).
Have you seen Mosync 2.6, I think this solves most of the problems you mentioned,
the feature list is at:
http://www.mosync.com/documentation/manualpages/whats-new-mosync-26-pyramid
I personally I'm quite excited about the whole HTML 5 integration, it sort of blurs the line between native and web app.
Hope this Helps
Tony