I am currently working on a Phonegap Cordova 2.5 app that requires the user to take a picture and upload it to our servers. I am using PhoneGap in order to avoid any Android specific coding (and possibly publish it on iOS some day).
As it turns out, Android frequently (but not always) kills my app while taking a picture and by the time the camera module returns a picture, my base app gets restored from scratch and no callback method gets invoked. Any reference to the newly taken picture is lost, see this post here:
Taking a picture from the camera fails 20% of the time
A common workaround seems to be native Android code. Which leads me to my question: Why should I use Phongap if the first and only Phonegap module I am using (the camera) needs some serious hacking? I am aware this is not even Phonegap's "fault" but rather Android life cycle design, but still: How can I defend this choice of architecture? Has it all been reduced to a reusable front end using HTML, CSS and JS? Should I switch to native Android?
Answering my own question: PhoneGap is awesome in many ways, so there are numerous arguments to defend it. Most notably, the whole UI needs to be coded only once and being Javascript and CSS there are many developers who don't need to learn another language. Don't underestimate the value of "easiness", if you need to code a relatively simple app, don't bother to go native. PhoneGap will just do fine.
In my case, the app I wanted to build revolves around taking photos. So I don't use the camera in some rare use cases to spice up the user experience, but it is rather the most important part of the app. In this scenario I guess the recommended approach is to go native. That's what I did in the end.
Another approach would have been using a PhoneGap Plugin called "Foreground Camera".
PROs: Seamless photo taking in the integration. The user actually takes the picture INSIDE your app.
CONs: By default you lose ALL of the camera's capabilities (zoom, front camera, flash, etc.), so you would need to make a serious coding effort to implement some of those features manually.
Related
I'm planning to create a BLE (Bluetooth Low Energy) mobile app for both iOS and Android devices. (iOS 11 or above / Android 6 or above)
I and my friend used both Java and Swift.
Although we searched about Xamarin or PhoneGap App,
we wanted to use our previous working environment (Xcode/Android Studio) as possible, not spending time on learning new tools.
So we want to work on a BLE app and we want to make it work on both Android and iOS. Currently, we are making the same thing using Swift and Java.
Since the UI part overlaps for both platform, we wish to ask these questions, please.
If we use Swift and Java separately, we noticed that when a picture is changed, we have to update both to each separate code.
For example, we wanted to change the round button to a square button shape. Currently, we upload the same picture to the GitHub repository respectively. So we felt something is not efficient and we want to ask is there a better way to change both sides of the app.
Solutions which require prices, like adding Amazon Web Service S3, is also welcomed.
We are creating the same UI for both platforms using Swift and Java. Since the UI, button, etc (the interface parts) overlaps for both app, is there a way to code the same UI so both of us don't have to spend time for working the same thing?
Maybe something like Xamarin could be one way, but I want to hear various advice, please.
Why not just put the images in a common folder in source control that both builds can access it? That's the common way of doing it. Using S3 (or any other server) will work if you want to download it at runtime, but since you tried checking it into source control it seems like you want it part of the build.
As for the UI- native Android and iOS have completely different UIs and ways of working with it. Really unless you want to go with an html app, you're going to write two different UIs. The UIs are the least sharable part of a mobile app. At least for business logic you have a few options (worst case you can always use C, which runs on both).
I'm about to start developing my first Android application, I have been reading through the developer documentation, but am unclear on how user interactions are handled.
As a front end developer, I use alot of css/jquery to create rich and interactive user interfaces.
I see that Android has it's own version of stylesheets, which seem pretty straight forward, but I am left wondering how I can replace something like js/jquery. Is it possible to use JQ mobile for native Android apps? Is there a replacement to this? Does android's UI handle this?
I'm a little confused.
Yes, it is still possible to heavily leverage your js/jquery skills and create a solid Android application that provides a rich user interface which is primarily js.
This will obviously depend greatly on what kind of application you're writing however if you own a website that delivers rich web content to end users and you'd like to replicate this in an Android application then you should take a look at webviews. They should support most of what you're trying to do in js or JQuery and it would be a quick process to mock up a test app to see if it meets you needs. I have run into a few quirks when replicating some interactive d3js visualizations which required extra tweaking before working properly on mobile devices.
I expect these minor issues will be ironed out in the next few releases of Android. Kitkat is going to include webviews that are based on Chromium which will include an updated version of the javascript engine. Your best bet is to just test it out, the amount of Java code required for a mock application is quite minimal.
Recently I dug into mobile development. I started with Android native, as it will probably be the first mobile OS the application will be published to, but after some struggles learning a new language, and trying to get used to new a IDE and API, I switched to PhoneGap, as it was always the plan to have the application on more than one OS. Additionally, I have years of experience with web development.
So now I come the issue I was facing, as my application will be handling a LOT of images, is how to store all these images.
I have couple of ideas of what could be done:
Have some sort of cloud storage which hosts the images, and then when application is run it would download all the images to the device, but that would take a lot of storage on the device and it might take too long.
Cloud storage, but when application is run it downloads them into a cache to just use the ones that are currently needed and then discard them after user is done with them, maybe even try to download just one by one when needed.
The 2nd approach makes the most sense to me regarding performance and device storage, but it would force the application to always be online. In the 1st example that would not be necessary. I can't help but think there is a better way to tackle this.
Also what would be the best path here to go native, which means tighter control of the native API, but losing the functionality of being generic and have to do the same thing for different OS in each language separately or in a ways stay somehow in hybrid environment?
My app does something similar to this, but we do it all in Java, so if you do decide to go back down that route, this could help. We have a large amount of images (more than 30,000) hosted in the cloud. The user can browse through these images (and we have pre-generated thumbnails of each) and on the client we have the following:
Placeholder image that is a subclass of ImageView, which also handles performing an asynchronous task of downloading the image.
Memory cache of images using Android's LRUCache class. The cache is initialized at startup to be about 1/8th of the available memory.
A DiskLRU Cache to store images on the phone's SD card. I'm currently using Jake Wharton's DiskLRUCache
This does a decent job, but you'll also want to look at Google's Managing Bitmaps article, and figure out how you're going to recycle bitmaps if you're running on Gingerbread or earlier.
Oh and I almost forgot, you might also want to look into Picasso
Phonegap/cordova apps are just native apps with most functionality in a webview, so you could leverage both the picasso code (via a native plugin) and use phonegap.
That said, I'd probably do what Carl does, but write a plugin for PhoneGap that calls into different native code for each platform.
Since you know the app is going to be cross platform, it makes sense to trial PhoneGap to see if it can perform well enough.
You could also look at doing the caching in js, leveraging some of the ideas here: https://github.com/bperin/imageCache
I am currently developing a native android app. My app has a lot of activities. I want to develop native android app. But in some case, I want to use a webview where the entire layout is just a webview. Not linear or relative or another layout, just a webview. All of the images and other things running in HTML. All of screen will run in HTML5.
So, I can partially transfer my app into iphone app or other platforms. This is the benefit of this way to me.
But I don't know. Is this way better? What will the performance be? What is the disadvantages of converting to an HTML5 app?
Can you explain?
There is a very good presentation about this very topic.
Performance: You are adding an additional layer in between, A webkit engine cannot always match native (and sometimes hardware accelerated) rendering performance.
Disadvantages: One is that the API use is limited, you can bind a page's JavaScript to Native code, but not all functionality is available.Though you might want to have a look at capabilities of Cordova project. Another is that emulating complex widgets via JavaScript will slow down the page.
Portability: Indeed is a great advantage, that's why PhoneGap and Cordova are popular. Though many like Facebook App etc have switched to native App for better performance.
The approach you require actually depends on your requirements. This may be my personal rant but IMHO: a markup can be only twisted so far, it can't out-perform industrial grade GUI programming setups as of yet.
Cons WebView
Can't use full performance of device, Since web view form an extra layer.
Web view can't listen all user event.
You can't fully share or save data from your web view to app.
Take more time to load. Other we get all things in a simple API and can be rendered.
Changing a simple fields in page need to load full page again.
Online required, can't extend offline features.
Orientation changes and full screen make difficulties.
Pros of using Web view
One page for both android and IOS.
I think the main advantage is the ability to make changes without the need for each user to update the app on his device, because all the pages are on your server.
No wait for app store approval for updation.
Some Techniques
Native elements TOGETHER with WebView. I think it will be much better, as there are a lot of functions that can't be done with WebView only. The combination of the two is much more recommended.
Rendering from locally, Create an assets directory for HTML files – Android internally maps it to file:///android_asset/ (note singular asset). So you can feed your web view form locally even if you are offline.
I think -by using this way- your app quality will be weak and app will be hard to use because the webview object not having a lot of tools that you can make it be compatible with android. e.g you can't share or save data from your webview to app. whatever that reference on your app what need and what dosen't need, by the way i tried to develop an app with html but it was bad.
We have an upcoming [big] project, involving a series of mobile apps. Unfortunately we're still new to this market. Our biggest problem is not learning something new, but rather having to develop the same app twice which means approx ~ twice the cost and Hence we're trying to find a cross platform solution.
Since our expertise is in C# and .NET we are very interested in MonoDroid/Touch, and from what I've read that it is a mature framework.
However it is not exactly cross-platform (or am I wrong ?) and so we turned to Phonegap, which lets you build mobile apps with js, css and html which are technologies which we feel comfortable using.
Our apps are going to be very data intensive and might also require to be "invoked" by the server, i.e. there might be 2-way communication between the server and the app.
and so my question, given these kind of apps would you suggest phonegap or monoTouch/Droid?
Thanks in advance.
Monotouch is NOT cross platform. It allows you to create reusable elements, but you can't build once and deploy to all platforms, especially if your project is really as complex as you are making it sound.
I don't know much about phonegap. I've always steered clear of it. It might have changed since I looked at it last, but as I gather its not very robust and doesn't create very good apps, especially (again) for a complex app.
There is another cross platform framework called Titanium, but similarly to the both above its not great. There is more support for it every day, but it is missing some key components and you tend to get so far into a project and realise that you're not able to get any further.
My answer, which you're not going to want to hear, is that you should do it for each platform separately, and charge your client as such.
Creating a mobile app cross platform is like creating a t-shirt that will fit everyone. Ok, so you can make it stretchy, and you can design it in a way that will "suit" everyone, but what you'll end up with is something that is going to be too big or too small, and no-one will enjoy.
iPhone, android, iPad, blackberry, windows phone 7, bada etc etc they're all VERY different platforms. Just because they're both mobile phones doesn't make them similar at all. The way that the UI is designed and displayed is varyingly different, and the way you interact with the hardware (and ultimately the user) is also different. Case and point - iPhone as you go down views you create a navigation stack which you navigate using a back button in the title bar (which has the title of the current view in it). Android you navigate with the back button on the device and the action bar is used for the app title and other "action buttons".
To this end I would suggest, if you REALLY don't want to do everything natively (which is definitely the best option) then I would suggest looking at Monotouch and creating two apps with reusable components.
With PhoneGap you will create a web application. It can look like a native app, but it's really a web app running inside a browser object.
You'll be programming the client HTML and javascript, just like any other client side web app. You can create ajax calls to the server to get your data and do all your usual C#/.Net stuff there.
With Mono, you will create a clients side application, and you can program that client in C#/.Net.
PhoneGap will be more or less free and can be used for other platforms than Windows, iOS and Android as well, though you'll have to setup environments for each version. You can compile for all platforms in the cloud, but that'll cost you money.
MonoTouch/Droid will set you back a few hundred dollars.
For each platform, you will have to do some extra tweaking. Probably giving it a native look and feel, call different API's, etc.
I would personally advise the Mono route, since you know C#/.Net already. It'll give you results faster. Make use of the free trial for MonoTouch and see if it's something for you and if it's worth buying ($698 for both 'touch and 'droid).
It depends.
I agree that going native gives you the best possible performance and user experience. It's certainly the only feasible option if the app has a demanding UI. But if the app is more informational (perhaps displays news feeds for example) then a hybrid HTML5 app could be the go. The support of HTML5 within a UIWebView on iOS has some quirks in the older iOS versions so tread with caution. And on Android and other platforms, HTML5 isn't quite there yet. Certainly not on older hardware that doesn't have the grunt or browsers with suboptimal javascript engines.
With your .NET background, I suggest you have a look at http://www.vsnomad.com and evaluate it for yourself. Throw a quick demo together and see how it holds up. Otherwise, yeah, go the native route.