We are making an app that will be basically the home for some Android devices.
Based on that, the idea is to have different partitions, for example, one for videos, one for apps and one for photos. What we want to achieve here is to prevent someone uses the entire storage capacity in recording a video, so with these partitions you can make videos until the videos partition gets full, and if this get full you still can install apps and take pictures.
So, here is the question. Is this doable? I know we have the option to make this via "logic", using folders and maintaining the used space count and make some validations. But the partitions approach seems to be more "clean and clear".
Can we make multiple partitions (external or internal storage)?
Can we save files to specific partitions? (I know that Android 4.4 provide some way of doing something similar but we are using Android 4.0/4.1)
Thanks in advance.
Related
HelloEveryone! I want to know some principal thing. Is there exists a method to take a picture (with good resolution) from android device without saving it in hard memory (only in RAM). I tried to:
use TakePicture(shutter, raw, jpg), but resolution of the resulting JPG is very low and RAW working with very few number of devices. Was asked here
give the control to Google Camera, but this way required some temporary file in the hard memory (to write picture)
How can I do this. Or is it impossible? Any help! Thank you!
It depends on your phone. Many phones do not need external sd card because they already have a internal one. So I suggest you check the hardware information of your phone first. If it do not have a external sd card, you can try to use camera2
to take videos and pictures. Pictures and videos can be stored in RAM. But if you want to access the pictures stored in RAM, you need to root your phone first.
I have a few projects with flash that i'd like to turn into apps for mobiles, I started reading adobe air and i've noticed that it uses back some things like inframe action script, something that I have not done since as2.
Is there a way to load scripts and classes like a normal flash file?
If I have a noncomplicated swf, is there a way to migrate it easily into adobe air for android and iOs?.
I've been struggling to find examples of adobe air projects, does anyone have a tip for this?
It is easy. I have converted 30 games to run on iOS and Android. The biggest problem was that they were in AS2 and had to be converted to AS3 first. If your uncomplicated swf projects are in AS3, and developed using Flash Pro, then just change the publishing output from swf for a web page to iOS pr Android. Android would be easier to start because you don't need to get an Apple developer account, create a certificate and provisioning file. With Android you can create a certificate right in Flash Pro. You test publish on your pc or mac first. When you are ready to test on a device you create an ipa (iOS) or .apk (Android).
Yes, there are a lot of screen sizes out there. But you know how you can create Flash in a web page so that it will resize with the page and keep its aspect ratio? Well its the same on mobile - it will resize to fit whatever mobile screen it displays on. Most likely your game is in landscape orientation. Just keep it that way and test it on whatever device you have (an iPad would be good because that aspect ratio or 1024 x 768). Actually, we kept the stage to 736 x 552 and that fit on any screen out there. On tall (wide) screens like the iPhone 5 & 6 you will have space on the sides, but so what.
Just give it a shot and you'll see how easy it is to write an app for both platforms at the same time. And you don't even have to own a Mac (you only need one to upload your completed app to the store, but you can rent time on one and log into it for 10 minutes to do that.)
There's no "how to" when porting a Flash project to Ios or Android. It's the same technology so it's compatible in theory. You can simply compile and publish and you'll get a Ios and Android app in most cases. Now there's 3 major problems that probably 100% of Flash projects will face when publishing for mobile and in probably 99% of cases those problems might imply recreating the whole thing from scratch.
First problem: Sizing and Density. So many phones/tablets sizes and density, chances are your Flash project doesn't have a single line of code dealing with that and as a result your app won't display correctly across any mobile devices. You'll have to put together a big piece of code to handle that and make sure it doesn't break anything in the original project. Good Luck with that.
Second Problem: Performance and memory management, I'm yet to see a Flash project that doesn't systematically waste CPU and memory constantly. That's no problem for a Flash project except when publishing for mobile: can we still waste CPU power? NO, can we still waste memory: NO. You'll have to go through your entire Flash project and optimize everything to not waste CPU and memory. Once again Good Luck with that.
Third Problem: assets. Did you use a bunch of MovieClip here and there? Well no more on mobile unless you want your app to lag and drain the battery down and make the user experience as bad as possible. All assets have to be optimized for mobile, the right asset, the right type, the right size or else ... lag and bad experience. Here again Good Luck with that.
And this is just a small run down of the problems you'll be facing. You will spend probably hundreds of hours trying to port that Flash project to mobile and at the end it will still be running bad anyway. Chances are you should just start over.
EDIT:
Simple Guidelines:
render mode: usually "gpu" (very efficient with bitmap) but "cpu" is also possible (you get more CPU power but less bitmap display efficiency) and also "direct" if you want to use Stage3D (more complicated).
Display: usually bitmap and only rarely vector. Don't oversize them and don't undersize them either. Reuse as much as possible (saves memory and battery)
Handling sizes and density: scaling your content is the easy way but not the less efficient one, as long as your bitmaps are of good quality you should be able to get a good resolution in most density and size. Because there's so many different sizes out there you'll decide if you want your content to fit any size or to display as much as possible while filling the side gaps. AIR/Flash has no built-in system for handling that so you'll have to create your own or to find something open source out there that can do that. Basically you have a content that is n x n and it needs to display on a mobile screen that is n x n, you calculate the scale factor and scale your content and center it.
perf, memory, battery: reuse object as much as possible. If there's a bitmap that you'll use often don't get rid of it just reuse it. If you reuse you don't need more CPU, don't need more memory and don't need more battery.
how to get perf: displaying something and running code, that's the 2 things that will slow down the app so optimize both and test often. Maybe reducing the quality of some bitmap will boost your perf. maybe optimizing your code in some places will get you a few more fps, etc. This is a per project try and test.
We are trying to build a photo app for a client where large photos are required to be fetched using a web service. These photos will be high resolution JPGs ranging in size (between roughly 5 - 7 mb).
The issue we're facing is how to fetch a batch of photos (say 10-15), store them locally on the app, and allow the user to perform editing tasks on them. What I understood from my team is if we edit the high resolution photos it will crash the app due to memory. This means we will have to reduce the resolution and size of the photo, which is reasonable, but could take a while. What is the best practice to download and reduce the photos so a good user experience is maintained?
To give some background, we are build the app for both Android and IOS. The features expected are typical swipe, pinch, editing with basic editing and advance editing like frames, text overlay, etc.
Not sure this is a UX question so much as about app architecture.
Maybe better suited to StackOverflow or another stack exchange site instead, but I'll try to approach it from a UX angle...
USER EXPECTATIONS
Do your users expect to edit high-res & have control over maintaining maximum quality? Or are they casual users just interested in making funny pix & won't care about loss of quality?
If they expect to have control, you could check disc space or device capability before downloading & offer them a choice of smaller size vs. slower response time.
For example, if they're on an older non-retina/low-pixel-density device, display an alert that editing high-res images might be difficult & offer a smaller version as an alternative.
How will saving/uploading edited versions work? Users might be upset if they overwrite originals w/lower quality versions & weren't given an option to "save as" or set quality level.
USE CASES & DEVICE SPECIFICS
Assumption: A user on a mobile device will only work on 1 image (maybe 2) at a time.
No mobile device is large enough to show multiple high-res images on screen at once anyway. Keep current image in memory; only show thumbnails of others (saved on disc) until requested for editing & then swap; release/reload resources as necessary.
If your users are using older hardware (pre-retina iPhone 3GS or iPad 2 for example), then a 5-7MB image (anything >3000px per side) might be a bit slow, but newer devices take/handle 8-12MP pictures themselves. Should be well within the device's capability to open/edit one at a time.
Are you saying this is not the case?? Can't even open 1 image? Is it being saved to disc first, or opened in-app directly from web service?
Verify adequate storage space either for the whole batch beforehand, or as each image is saved
If device storage is full, cancel remaining downloads & alert user which images are missing
USABILITY & RESPONSIVENESS
Download the images asynchronously to avoid blocking the UI
Create much smaller low-res thumbnails to act as a placeholder for the high-res versions. Download & show thumbnails first to give a sense of progress, but differentiate between an image that's still loading & one that's available for editing (with a progress bar, transparency, etc).
Download in the background (as you might an "in-app purchase") and save to disc.
Download individually & save to shared location. This keeps them organized as a batch of 10-15, but lets the user start working as soon a the 1st image is available. Don't make them wait for all of them.
Could use a separate "downloads" view w/progress bars & let user continue work in another tab/view
Only once the user selects a thumbnail do you need to worry about loading/displaying the large version from disc. You can release thumbnail/loading view from memory & free up resources if necessary while the large image is being edited. Reload only as necessary.
Auto-save to disc in background to prevent loss of work & take opportunity to clean up caches & whatnot.
If working memory is already a concern, you won't have many options for undo/redo. Most image-editing apps manage this ok though, so there's a way.
I'm developing an HTML5 application having lots of animations and logic running behind it.
Large number of images and audio files are used in the application to achieve better UI and UX.
I think when I complete this app, It'll be of more than 250 mb in size.
For the web, it wont be any issue since I divided each every modules to several of html pages.
But what if I need to package it with phoneGap for Android Tab and iPad.
Is it possible package an app with large size?
Is there any other method to package it with smaller size?
Any help would be appreciated.
Thanks in advance.
I have a Cordova app here that is well over 1GB. As long as you stay within other limits like the 2GB maximum for the app store, size shouldn't be a problem.
You will need to build locally of course - PhoneGap Build has a hard file size limit, and cloud build services are generally impractical for anything that large.
If possible, set up your app so that it can easily be packaged without most of the media for debugging - the full version takes forever to build and deploy.
I’m having a little problem with an app I’m working on. The app shows a gallery that shows between 1 and 70+ pictures (one at a time), all downloaded from the web.
At first I save a low resolution picture and after I finish downloading all low res pictures, I start downloading the high resolution ones and replacing them.
The problem comes when I start downloading the high dpi ones. After some are downloaded I get a memoryOutOfBoundsException (which can be expected).
To solve that kind of problem in android I’ve seen four options:
1.- Using androids Cache Manager.
This is limited to Web Views (So I can’t use them).
2.- Loading the hi res picture every time the user passes thru a picture.
That will make the bad resolution picture appear every time the user changes the picture until the high resolution one (which is loading on the background) gets downloaded and switched. Making the application look bad.
3.- Creating some kind of RAM cache that can hold like 5 pictures and use something like the second method.
In this case, I’ll try to have, in the ram, the 5 hi res pictures nearest to the one that is being showed (either downloaded or being downloaded) so that the app can show hi res pictures for the ones that are near the selected one without having to download them after the user gets to see the low res picture.
4.- Creating a personal Cache Manager
In this case I’ll create a personal cache manager that saves the pictures on the SD card and uses those pictures on the gallery. This also brings one problem, I’ll depend on the user having an SD card on the device. For solving the problem of the files staying on the device after the app is deleted (If the app gets deleted), I’ll just delete all the files on the onDestroy() method of the app (I don’t mind loading them again).
In my opinion, the best option is the fourth. Method, which forces me to depend on the user having an SD card.
Now my questions.
Is there any other way of solving my problem?
Is there another kind of memory on the device than can be used to evade the dependency of the SD card?. Following the question. Is it recommended to use that kind of memory or does using it bring other problems?. (Also, a tutorial about it wold be apreciated.)
Do users usually have SD cards or is the fourth option the worst one?
Thank you in advance.
I would write my own cache manager. If the user can only load pictures to the left and right in the list, I'd keep those three in memory if possible and shift every time the user navigates to a new picture. I'm not sure if that's how your app works, but that's one way of doing it. If you can't predict your user's next choice, maybe have a revolving cache and experiment with how many you can hold in memory at once (not knowing the best, worst and average case of your file sizes, I can't really speak much on that).
You may know this already, but it's always worth mentioning. When you're working with Bitmaps, any time you're done with one...really done with it (such as flushing it from your cache), call it's recycle method. That seems to be the quickest and most widely accepted way of reclaiming that memory for the system.