code • DRY KISS - Always • Be weary of memory usage • Try to use libraries as external JAR files. - modularity - easier development sloop • If you comment something out.. Erase it.. You will probably never use it again
the ArrayList in the mobile world, it matters… • Android uses a Google re-written Java, so most of the standard java classes you use are “optimized”, optimizations have bugs ☺. • Cleanup code before using it.. The Android compiler does not exclude unused classes. This will greatly reduce your application size
SDK, and a target device. Maybe the code can be uniform and meant for all device, but the UI cannot. • Forget String-s use StringBuilders • Use a Debug condition for your Log statements. Remember that : logs concat strings and are NOISY! • Android has a GC, but System.gc() doesn’t work! Have it in mind…
object to which the view is refering • Use it on buttons to hold a state, or reference • Use it with cursor adapters to hold an object or database ID • Use it with custom views to hold misc data for the extra data you need.
use adapters from databases or webservices. The notifyChange() method is very important for automatic update and/or content change. Whenever you insert/update any data in the source it is important to call this method to tell all the users to refresh or re-query their data.
half open - This wreaks havoc in the android heap and memory management, Never forget to cursor.close() - If this is hard, then either call the manageCursor to link the cursor to the activity lifecycle or use cursor helper.
handy, but developers over or under use them very often. - Handle the system services (layoutInflater) - Inflate to combine layouts, much better and easier than writing it in code. - Don’t forget to recycle the Inflated layouts ! - Externalize ALL Strings to strings.xml - Use values for system configurations
are difficult for the GPU to render and refresh. Views should be simple and a better resolution is for the view hierarchy to be wide than tall. Use the HierarchyViewer tool to find the skeleton of your activity.
very difficult error to trace - No Java StackTrace - No Error screen However if you look at the debug dump, you can see That the heap is being overflowed. To check Runtime.getRuntime().maxMemory() – heap size
help them self with memory) Or: - Avoid operations that require threadpools. Control your background processes. - Try to find out if you overuse strings since + is a very heavy duty operation! - Use MemoryAnalyzer to find the “memory hoag”
and huge bitmaps java.lang.RuntimeException: No memory in memObj at android.database.CursorWindow.native_init at android.database.CursorWindow.<init> at android.database.CursorWindow.<init> at android.database.CursorWindow$1.createFromParcel at android.database.CursorWindow$1.createFromParcel at android.content.ContentProviderNative.onTransact at android.os.Binder.execTransact at dalvik.system.NativeStart.run