To fix the OutOfMemory error, you should do something like this:
BitmapFactory.Options options = new BitmapFactory.Options();
options.inSampleSize = 8;
Bitmap preview_bitmap = BitmapFactory.decodeStream(is, null, options);
This inSampleSize
option reduces memory consumption.
Here's a complete method. First it reads image size without decoding the content itself. Then it finds the best inSampleSize
value, it should be a power of 2, and finally the image is decoded.
// Decodes image and scales it to reduce memory consumption
private Bitmap decodeFile(File f) {
try {
// Decode image size
BitmapFactory.Options o = new BitmapFactory.Options();
o.inJustDecodeBounds = true;
BitmapFactory.decodeStream(new FileInputStream(f), null, o);
// The new size we want to scale to
final int REQUIRED_SIZE=70;
// Find the correct scale value. It should be the power of 2.
int scale = 1;
while(o.outWidth / scale / 2 >= REQUIRED_SIZE &&
o.outHeight / scale / 2 >= REQUIRED_SIZE) {
scale *= 2;
}
// Decode with inSampleSize
BitmapFactory.Options o2 = new BitmapFactory.Options();
o2.inSampleSize = scale;
return BitmapFactory.decodeStream(new FileInputStream(f), null, o2);
} catch (FileNotFoundException e) {}
return null;
}
This will eventually get to your question, but I first want to address a number of issues you raise in your various comments to the various answers already given at the time of this writing. I have no intention of changing your mind -- rather, these are here for others who come to read this post in the future.
The point is that I cannot allow for
Android to determine when my app is
going to be terminated. that must be
the choice of the user.
Millions of people are perfectly happy with the model where the environment closes up the application as needed. Those users simply don't think about "terminating" the Android app, any more than they think about "terminating" a Web page or "terminating" a thermostat.
iPhone users are much the same way, in that pressing the iPhone button does not necessarily "feel" like the app was terminated since many iPhone apps pick up where the user left off, even if the app really was shut down (since iPhone only allows one third-party app at a time, at present).
As I said above, there is a lot of
things going on in my app (data being
PUSHed to the device, lists with tasks
that always should be there, etc.).
I don't know what "lists with tasks that always should be there" means, but the "data being PUSHed to the device" is a pleasant fiction and should not be done by activity in any case. Use a scheduled task (via AlarmManager
) to update your data for maximum reliability.
Our users log in and can't be doing
that every time they get a phone call
and Android decides to kill the app.
There are many iPhone and Android applications that deal with this. Usually, it is because they hold onto login credentials, rather than forcing users to log in every time manually.
For example, we want to check updates
when exiting the application
That is a mistake on any operating system. For all you know, the reason your application is being "exited" is because the OS is shutting down, and then your update process will fail mid-stream. Generally, that's not a good thing. Either check updates on start or check updates totally asynchronously (e.g., via a scheduled task), never on exit.
Some comments suggest that hitting the
back button does not kill the app at
all (see link in my question above).
Pressing the BACK button does not "kill the app". It finishes the activity that was on-screen when the user pressed the BACK button.
It should only terminate when the
users want to terminate it - never
ever any other way. If you can't write
apps that behave like that in Android,
then I think that Android can't be used
for writing real apps =(
Then neither can Web applications. Or WebOS, if I understand their model correctly (haven't had a chance to play with one yet). In all of those, users don't "terminate" anything -- they just leave. iPhone is a bit different, in that it only presently allows one thing to run at a time (with a few exceptions), and so the act of leaving implies a fairly immediate termination of the app.
Is there a way for me to really quit
the application?
As everybody else told you, users (via BACK) or your code (via finish()
) can close up your currently-running activity. Users generally don't need anything else, for properly-written applications, any more than they need a "quit" option for using Web applications.
No two application environments are the same, by definition. This means that you can see trends in environments as new ones arise and others get buried.
For example, there is a growing movement to try to eliminate the notion of the "file". Most Web applications don't force users to think of files. iPhone apps typically don't force users to think of files. Android apps generally don't force users to think of files. And so on.
Similarly, there is a growing movement to try to eliminate the notion of "terminating" an app. Most Web applications don't force the user to log out, but rather implicitly log the user out after a period of inactivity. Same thing with Android, and to a lesser extent, iPhone (and possibly WebOS).
This requires more emphasis on application design, focusing on business goals, and not sticking with an implementation model tied to a previous application environment. Developers who lack the time or inclination to do this will get frustrated with newer environments that break their existing mental model. This is not the fault of either environment, any more than it is the fault of a mountain for storms flowing around it rather than through it.
For example, some development environments, like Hypercard and Smalltalk, had the application and the development tools co-mingled in one setup. This concept did not catch on much, outside of language extensions to apps (e.g., VBA in Excel, Lisp in AutoCAD). Developers who came up with mental models that presumed the existence of development tools in the app itself, therefore, either had to change their model or limit themselves to environments where their model would hold true.
So, when you write:
Along with other messy things I
discovered, I think that developing
our app for Android is not going to
happen.
That would appear to be for the best, for you, for right now. Similarly, I would counsel you against attempting to port your application to the Web, since some of the same problems you have reported with Android you will find in Web applications as well (e.g., no "termination"). Or, conversely, someday if you do port your app to the Web, you may find that the Web application's flow may be a better match for Android, and you can revisit an Android port at that time.
Best Answer
Important Update : As @equiman points out, there are some USB cables that are for charging only and do not transmit data. Sometimes just swapping cables will help.
Update for some versions of adb,
~/.android/adb_usb.ini
has to be removed.Executive summary: Add the Vendor ID to
~/.android/adb_usb.ini
and restart adbFull Details: Most of the time nothing will need to be done to get the Mac to recognize the phone/device. Seriously, 99% of the time "it just works."
That being said, the quickest way to reset adb is to restart it with the following commands in sequence:
But every now and then the
adb devices
command just fails to find your device. Maybe if you're working with some experimental or prototype or out-of-the-ordinary device, maybe it's just unknown and won't show up.You can help adb to find your device by telling it about your device's "Vendor ID," essentially providing it with a hint. This can be done by putting the hex Vendor ID in the file
~/.android/adb_usb.ini
But first you have to find the Vendor ID value. Fortunately on Mac this is pretty easy. Launch the System Information application. It is located in the
/Applications/Utilities/
folder, or you can get to it via the Apple Menu in the top left corner of the screen, select "About this Mac", then click the "More Info..." button. Screen grab here:Expand the "Hardware" tree, select "USB", then look for your target device. In the above example, my device is named "SomeDevice" (I did that in photoshop to hide the real device manufacturer). Another example would be a Samsung tablet which shows up as "SAMSUNG_Android" (btw, I didn't have to do anything special to make the Samsung tablet work.) Anyway, click your device and the full details will display in the pane below. This is where it lists the Vendor ID. In my example from the screenshot the value is
0x9d17
-- use this value in the next commandIt's okay if you didn't already have that
adb_usb.ini
file before this, most of the time it's just not needed for finding your device so it's not unusual for that file to not be present. The above command will create it or append to the bottom of it if it already exists. Now run the commands listed way above to restart adb and you should be good to go.