Upgrade to Pro — share decks privately, control downloads, hide ads and more …

The good the bad and the ugly things to do with...

Tancho
April 11, 2011

The good the bad and the ugly things to do with Android

presented back in 2011
The good the bad and the ugly things to do with Android

Tancho

April 11, 2011
Tweet

More Decks by Tancho

Other Decks in Technology

Transcript

  1. Mobile2Days The Good, 
 The Bad, 
 and The Ugly…


    Things to do with Android Stanojko Markovik 04.11.2011@Java2Days
  2. Your presenter… • Speaks a few languages (Java, C++, Python…)

    • Currently works at the ARTEMIS R&D department at SudParis Telecom Institute • Worked with android from v1.1 both for app development and custom ROMs • Linux geek • JUGMK member
  3. • Good practices and the proper way to do things

    1 • Bad things people tend to do and how to evade… 2 • The ugly things no one wants to talk about. 3 What will we talk about??
  4. The standard stuff first • Always keep Clean and concise

    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
  5. Android Specific stuff - UI • Android uses a modified

    version of the MVC patter, 
 Views are made in XML. 
 Populated by code • Android is aware of the display size. So use this, and have different graphics. For each size of the screen
  6. Android Specific stuff - UI • Try to utilize the

    9patch drawables as much as possible Example 1 Example 2
  7. Android Specific stuff - UI • If the shapes are

    simple.. Write them in XML Sample Round shape definition in XML
  8. Android Specific stuff - Code • Differentiate the LinkedList from

    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
  9. Android Specific stuff - SDK • Always have a target

    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…
  10. Android Specific stuff 
 Visual Scaling • Try to get

    used to thinking in DIPs and SP. • A good developer always wraps his content! • Android has a GC, but System.gc() doesn’t work! 
 Have it in mind…
  11. View.getTag() method This is the “hidden” pocket meant for the

    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.
  12. notifyChange() method Very often you have to write applications that

    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.
  13. Database Cursors • Database connections are often left open or

    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.
  14. Use XML resources with care XML layouts are a very

    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
  15. Don’t over nest “Lazy” developers tend to overuse the LinearLayout

    Instead of using RelativeLayout Eclipse Demo here…
  16. Cursor adapters and lists • Use relative layout for the

    list items • Use recyclable views and adapter • Load images in the backgroud 
 Eclipse Demo here…
  17. Background and Services • Differentiate when to use binded and

    unbinded services. • Understand the onStartCommand() method and it’s return statement. • Differentiate threads and asynctasks • Never use Toast or Dialog from a service
  18. View Hierarchy Developers tend to create complex view hierarchies which

    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.
  19. ANR • Affected : 
 Activity, Service, BroadcastReceiver • Reason

    : 
 Lifecycle rules broken • Fix
 Run heavy processing outside of the main thread, use asynctask or another thread.
  20. Fantom Apps - The Cause In general this is a

    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
  21. Fantom Apps - The Solution VMRuntime .getRuntime().setMinimumHeapSize(BIGGER_SIZ E) (how googers

    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”
  22. Bitmaps and Graphics Android 2.x does not work with bitmaps

    well • VM does not load Bitmaps in heap, • Bitmaps are immutable • Matrix transformations are EXTREMELY risky
  23. Bitmaps and Graphics Repetitive problems ERROR/AndroidRuntime(7906): java.lang.OutOfMemoryError: bitmap size exceeds

    VM budget ERROR/ AndroidRuntime(7906): at android.graphics.BitmapFactory.decodeFil e(BitmapFactory.java:295)
  24. Other Memory issues This is actually caused by unclosed cursors

    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
  25. The problem You are stranded with a slow application. •

    Memory is failing • Application is Slow • Sometimes it fails • Sometimes it just “dissapears”
  26. Threads vs. Async Tasks • Async Task Queue Limit •

    Thread overrun • AsyncTaskEx • NeverEnding cursors
  27. Again the notifyChange() method This can sometimes wreak havoc. An

    example (that happened to me): I download news from a website, upon download I have a list of 50 items. NotifyChange() is called 50 times! Definition of an UGLY SCENARIO
  28. The logging facility Android Log is great, but People tend

    to 1. Overlog 2. Forget the logs 3. Concatenate a huge amount of strings 4. Leave logs in loops (for, while, do-while) 5. Add stupid tags 6. Offer the consumer private information
  29. It’s Hard No, It’s not! It’s fun! It’s easy! It’s

    lucrative ☺ It’s cool! New Employee 1 yr 2 yr 3 yr
  30. You only have to : 1. Be aware of the

    rules of engagement! 2. Know your target 3. Be weary of memory! 4. Remember that it’s a VM 5. Have Respect for the other platforms, and you just might learn something new…
  31. Q&A