I am using flash builder to make an app for android/ios.
How would you recommend I use assets such as images and sounds. Should I embed them or use loader?
Any benefits to each one.
I have a fair amount of assets.
I am no expert on flash, but I ended up embedding the resources. The ease of compile-time resource checking. You just need to be sure to load each images/sounds when you have enough time to do so between frames.
For mobile apps embed is just easier. You don't need to worry about accessing the file system and purchasing/downloading is easier since you are not bundeling anything with it. The initial download will be about the same size unless you were planning on loading the assets to the device at runtime from the web. I would caution against that unless it was absolutely necessary. My experience is user are accustomed to a large download, but but load time of the app each time it opens should be minimal.
I also like that FlashBuilder will check your embed code and make sure the file is present and spelled correctly - one less thing to worry about
Related
Hi i'm trying to make my HTML webpage offline for android and IOS devices. My problem is that I need to store a lot of data. This data (css,js,images,html) needs to be persistent. (even after shutdown of the device)
USE: Someone types the URL and gets the whole page offline available.
What is the best way to persist your data? and is it possible without making a hybrid or native app, just with caching and maybe appcache/indexeddb.
EDIT: i have found that indexed db in combination with dexies my best guess is for a solution. are there any do's or don'ts, alternatives or tutorials you guys suggest ?
depending on the application personality I sometimes render the entire site/application in the service worker when the service worker is installed/activated.
I wrote about an example app I did last October for a conference, https://love2dev.com/pwa/pubcon/
As far as strategy, I vary things. For data (think JSON) I tend to cache in IndexedDB (I like localforage b/c it is simple).
For site assets (HTML, JS, CSS, Fonts and often media) I use service worker cache.
If a site is heavy on media, I persist images and video in IDB b/c iOS limits service worker cache to 50MB. 50MB should be more than enough for any web application core assets as they should really be measured in kb, not MB anyway.
iOS gives you several GB of IDB storage, depending on how much disk space is available on the device.
I have built multiple SAAS apps using this strategy and never hit data quotas. Of course lots of video or images will of course consume more space and you need to watch for quota exceeded errors.
Users will also be prompted to give permission for extended storage as well, so be aware of that barrier as you may need to educate the user about this.
I am building an android app which requires to have >300 images and ca. 100 audio files for an apk size of around 50mb (after webp compression and proguard).
It is not huge and I could probably live with that. But since I am planning to add other features the size will get bigger and bigger.
I am still interested though, since I'm quite new to android development, if there is a better way to store all this files, perhaps remotely and access them when required.
When the app starts I would have to load all the images into a list and once an element of the list is tapped I would need to open a separate activity and load the sound. So there is no upload from the App, just a resource gathering.
I do not know if it is more efficient this way or to store all the files locally.
Either way I would like to know what my options are. what are the pros and cons of a server (and if it would be a viable solution for me at all) and what is the advantage of storing them locally instead.
Please keep in mind that I working by myself and haven't got money to invest on premium servers or stuff like that.
FILE STORAGE will be best for you. Performance depends on the type and amount of data you are using. You do not need too much of data manipulation so go for file storage if privacy is not your concern for the data as it will be available for all the applications.
Use SQLite Database if the files needs to be protected from other applications.
Use File Storage(internal/external memory) if other applications can also access your files.
Avoid Fetching data from server using JSON parsing/Http requests it will make your app rely on the internet all the time. Unless you are using it to update your database or file storage.
I am rendering a webview on button click and am using the shouldInterceptRequest to intercept requests to resources like images, css and js files and serving them locally instead of over the network. I expected to see a considerable amount of difference in the load time but it reduced only by a small fraction. Is it possible to parallelize the shouldInterceptRequest ?Are there any other suggestions.
Thanks in advance
The new Chromium WebView present in KitKat will read multiple InputStreams returned from shouldInterceptRequest in parallel. The Classic WebView implementation present in previous versions of Android would perform the reads serially and there is no way around that.
Without knowing the details of the content you're trying to serve it's hard to offer specific suggestions. How are you measuring this? Maybe the total time to display went down, but you perceive the load as being slower because only one thing is loading at a time? You should also try experimenting with what to cache locally - maybe the biggest gain is from only having the biggest file be served via shouldInterceptRequest?
If you can afford the extra memory usage you could store your resources in memory (by reading them into a string, for example) and serve them to the WebView using a ByteArrayInputStream. It would be ideal if you could predict what the next required resource would be (that way you'd need less memory).
Note: the Classic WebView would use shouldInterceptRequest "under the hood" for reading file:///android_asset and content: scheme resources, so there is no benefit in transferring between any of those, however doing so (specifically using the file:///android_asset/) might simplify your code.
As far as I know, swf's and gif's inside WebViews are not officially supported by Android, eventhough they work in my HTC Desire Device.
I'm building an app that it's all based in a WebView. What i did is code the 'app' as HTML, put it into the 'raw' folder and once the app starts, it puts all the htmls and images into a folder on the SD (if they're not there yet).
Now I need display some animations in there. I made them with Actionscript and I was glad that it seemed to work (Animations were 25KB each), but after a while publishing it, i got reports from people that coulnd't see the animation.
Then I patched them into a GIF (raised memory to 400KB-1MB each). At this point, I decided to take the gifs out of the raw folder, and download them from one server in the web the first time the app runs, so my apk doesn't get too big. But I get complaints again that people can't see it (then I found that GIF is also unsupported)
Google-ing and stackoverflow-ing I found that the only solution is to split those GIFs into separate images and show them with javascript one by one to create the animation. I guess this method is OK for small animations (like some face saying hello or something like that), but for whole animations.... It weights about 3MB per animation (when the swf was 25KB...). And I think taking 30MB (possibly more in the future for new animations) from user's data quota is not nice.
So:
Is there any other solution?
Are there lots and lots of phones that don't support SWF? and GIF? If they're not too many, I would consider putting on my app's description that the animations won't work if the phone has low memory (animations are not very important into my app)
Thank you very much,
Víctor
edit: Additional information: Animations are like this one.
So... I found the only way was to use HTML5 canvas animation, since surprisingly it is supported by many devices.
The animation is not as smooth as in a GIF-compatible device, but I rather make it accessible for everyone.
So, CommonsWare answered my 2nd question, but I will answer my 1st one: Yes, use HTML5. It didn't take a huge work, since JS can be Object-Oriented as well, and syntax is fairly similar to AS3.
And the best part is that the base code only weights 34KB (let's say the engine plus all the images), and each animation (in a separate file) weights between 1 and 2KB. That was awesome, I can put them all into my Android's raw folder.
Thank you very much CommonsWare for your comment.
I have to make an application that should capable of reading PDF documents on Android device. Actually I do not want my app to be dependent on other apps to read the PDF file.
I had gone through the questions that are asked here and at some other places also. They all directly or indirectly using third party app.
Is there any API or something similar is available through which I can implement reading of PDF files directly in my app? How about converting the PDF document to PNG image? But the PDF-PNG method wont let users select the texts.
Any suggestions?
Thanks
There exists an library from Adobe that you can use. Its based on the NDK and you need to do the wrapping all by yourself. Its also extremely expensive, basically nothing for a small firm/single developer but for bigger companies. Afaik the license is not only expensive but also annual based, so you need to pay for it in every year...
There are other libraries, basically open source. Some of them have good performance but a lack of functionality (most of them based on NDK, too). I found only one pure "java" library but the performance was more than worse (loading time 10sec for a page and more).
There are three possibilities you should consider:
Using an external application, so you just need to implement the library of your PDF documents
You write everything by yourself including a pdf reader part
You create a middle "tier" where you convert your PDF into PNGs or JPG (I prefer PNG for better quality). The much better performance comes with a lack of features.
I'm currently developing a complex application like mentioned in 3. but I can't go into details, sorry.
I would definitely recommend the Qoppa stuff on Android.