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
Related
Is there more to the React Native Prefetch feature than simply calling that URL like this:
var prefetchTask = Image.prefetch(IMAGE_PREFETCH_URL);
Attempting to load an image into cache so when I choose to display it into my app it is quick, and I am using the code above, however I can't really notice any sort of load speed difference, where it feels like it should definetly have been quicker...
I am using Android.. It seemed like this was available for both platforms..
Any other solutions for caching images?
Not sure about it, but it might be that the delay you are noticing is the time it takes the app to render the image, and not to download it (which might be quite faster, specially if you are running your app in debug mode). You can try to time it using the onLoadStart/onLoadEnd methods of the <Image> (see the docs and the example). As for other caching solutions, you might want to check some third-party packages, such as react-native-cacheable-image or react-native-cache-image.
I've looked at this doc: http://developer.android.com/guide/webapps/webview.html
It seems it might be attractive strategy to use HTML/Javascript to get:
result faster (I can use my browser to create a prototype very quickly, just updating my page in the browser, and not waiting for emulator to be update my changes)
avoid to to learn Android API too deep (but use what I know HTML/CSS/JS instead)
reuse my code, putting it to iOS, BlackBerry (not only Android)
The only question I have.. Is whether someone already did it for real? Because tutorials that I've found - just show how to print 'Hello world!' message in simple HTML.
But what would be more interesting to get is 'how it works with embedded database' in android,
OR better say, as an example what I mean:
How to handle JS' "onClick" to get some data stored to db?
UPDATE:
Yeah.. there are a lot of PRODUCTS. But what if I need just a storage support (need to put and read data from db). no need anything sophisticated like camera support. What I really want to avoid is:
waiting for Emulator updated
write simple and easy components and layout in HTML to get instant result (it seems more natural for me, even though I'm Java Dev.. but it's lame to wait for result building and waiting when working with UI)
I'm looking for someone's existing experience to avoid addition complexity and time gaps between builds/tries while working with UI.
Look into Phonegap to convert HTML, CSS, and JS code into a native phone app for android or iOS. Very useful as it puts a web wrapper around the web code to run it natively on your phone. This should solve storage issues as well, lots of documentation around for phonegap, be sure to check it out!
I just released http://www.protocoder.org under MIT license, give it a try! Its meant to basically do what you mention in the first point (prototype fast), and on the second avoid to learn the Android API to deeply.
Its still a young project but I hope it will grow really fast :)
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.
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.
I want to write an Android application to read and display PDFs. I don't want to use any third-party applications to do this, because I don't want to force my users to download those applications. And I don't want to use a webview, because then users won't be able to use my app when they're offline.
How might I approach this?
Here's a link I used to create one that mostly works.
It outlines how to write (and hence read) all the common PDF parts that are in a .pdf file. It's far more readable than the ISO spec, especially if you haven't done PDF formats before.
http://www.adobe.com/technology/pdfs/presentations/KingPDFTutorial.pdf
Good Luck.
Unless you fancy building a PDF rendering engine from scratch (or including one in your project), you probably are better with using some kind of intent to ask some other application on the phone to view the PDF. I know you do not really want the requirement of having an application installed to handle it, but I suggest that you are probably adding unnecessary complexity to your application by trying to do it some other way.
It's worth mentioning that quite a lot of Android handsets already have PDF viewers preinstalled, and incidentally, I think even WebView requires that the phone has a PDF viewer installed!