Confirmed users
400
edits
Mobile/Fennec/Android/AdvancedTopics: Difference between revisions
Jump to navigation
Jump to search
Mobile/Fennec/Android/AdvancedTopics (view source)
Revision as of 02:06, 11 September 2015
, 11 September 2015→Coding Gotchas
No edit summary |
|||
| Line 129: | Line 129: | ||
followed by errors about "C compiler cannot create executables", "Relocations in generic ELF (EM: 40)", and "crtbegin_dynamic.o: error adding symbols: File in wrong format". This is a sign that you're compiling with your platform's native compiler (due to having CC / CXX set), instead of the android-specific GCC version that ships with the NDK. See {{bug|977817}} for more details; as noted there, the build system may trust your custom CC & CXX variables, when you probably don't want it to. | followed by errors about "C compiler cannot create executables", "Relocations in generic ELF (EM: 40)", and "crtbegin_dynamic.o: error adding symbols: File in wrong format". This is a sign that you're compiling with your platform's native compiler (due to having CC / CXX set), instead of the android-specific GCC version that ships with the NDK. See {{bug|977817}} for more details; as noted there, the build system may trust your custom CC & CXX variables, when you probably don't want it to. | ||
=== Coding | === Coding Caveats === | ||
==== Closing resources ==== | ==== Closing resources ==== | ||
When handling resources (like Cursors), a try/finally block should be used to ensure these are closed properly. For example: | When handling resources (like Cursors), a try/finally block should be used to ensure these are closed properly. For example: | ||
| Line 167: | Line 167: | ||
This is so that in case of ClassCastExceptions you don't get a dangling open resource left behind. | This is so that in case of ClassCastExceptions you don't get a dangling open resource left behind. | ||
==== | ==== Timing ==== | ||
TLDR: Google recommends using SystemClock.uptimeMillis() for general purpose interval timing of user interface events or performance measurements. If you're adding stuff for timing, use SystemClock.uptimeMillis(), rather than something like new Date().getTime(). | TLDR: Google recommends using SystemClock.uptimeMillis() for general purpose interval timing of user interface events or performance measurements. If you're adding stuff for timing, use SystemClock.uptimeMillis(), rather than something like new Date().getTime(). | ||