kanAVatar

Given the prevalence of mobile devices in the workplace, a lot of enterprises have embraced an EMM strategy. But if you are looking to get your feet wet in this domain you might get confused with the barrage of acronyms and options you have there. Let me help you navigate the waters: BYOD (Bring Your Own Device):  Is basically when employees can use their personal devices for business tasks. COPE (Corporate Owned, Personally Enabled):  The counterpart to BYOD, where the enterprise owns the devices and the employees configure the device to suit their needs. MDM (Mobile Device Management):  This was the first solution to the ‘infiltration’ of mobile into the workspace. As the name suggests, with this solution employers would have the power to manage and control the entire device. Common examples would be to force a passcode for the device or to remotely wipe all the data from a lost device. While an MDM solution might work for a COPE scenario, it was highly unpopula...

From  http://tools.android.com/tech-docs/configuration : You can also place use environment variables to point to specific override files elsewhere: STUDIO_VM_OPTIONS , which vmoptions file to use STUDIO_PROPERTIES , which property file to use STUDIO_JDK , which JDK to run studio with Note that this last variable allows you to for example run Android Studio with Java 7 on OSX (which normally picks Java 6 from the version specified in  Info.plist ): $ export STUDIO_JDK=/Library/Java/JavaVirtualMachines/jdk1.7.0_79.jdk $ open /Applications/Android\ Studio.app

Another self help book full of platitudes. But it did have some interesting anecdotes and thought provoking aspects to it. Here are my take aways from it: Even if you are not a manager, you should strive to enhance your influence in your organization. I feel the best way to do this is to help others- they could be in your team or another team, but you never know when you might need them to return the favor! "Influence must be earned." "The person who keeps busy helping the one who is below him won't have the time to envy the person above him." Try and network more. Easier said than done, but it would be good to strike up conversations with folks while in the elevator, while getting coffee...you get the idea. The problem here is not that you know this needs to be done, it is how you actually do it. Different ways will work for different folks, but it is good to keep this at the back of your mind. Maybe you could try and setup some knowledge sharing session...

From http://androidcookbook.com/Recipe.seam?recipeId=2688 onSaveInstanceState(Bundle) and onPause() Use onPause to save data that should be preserved long term, use onSaveInstanceState for transient states. For example in a game the current score could be saved in onSaveInstanceState and only saved in onPause if it was good enough for the High Score table, in which cause the High Score table (in SharedPreferences, a database table, or a file) is updated. onSaveInstanceState\onRestoreInstanceState and the Android Lifecycle The SDK documentation says that  onSaveInstanceState(Bundle)  may run just before or just after  onPause() . As for onRestoreInstanceState(Bundle)  that occurs after  onStart()  and before  onResume(). onSaveInstanceState() is not called when the user navigates to another activity. So if the user presses the back button, this callback won't be called. But if the Android home button is pressed this callback is call...

It is good practice to not do computation intensive work on the UI Thread. In fact starting from HoneyComb, you get a NetworkOnMainThread exception if you try and do any network processing on the main thread. So we should do background work in a new thread. One thing we need to consider is that only the UI thread can update the UI, so when our background thread wants to update the UI, we need a means to communicate between threads. Actually even your background thread can update the UI, but this is really dangerous and your app can crash! Android provides a lot of multi threading constructs for us. AsyncTask is by far the easiest way of multithreading in Android. When you create a new AsyncTask object the framework creates a new thread for you and provides methods to communicate with the UI. No threads, no handlers and no Executors (Because it uses these classes internally)! So why not use AsyncTask all the time? Well, because these are suited for background work that typically l...

To set them, export VAR=1 To check them, printenv To unset, unset VAR. On Ubuntu, you can set vim ~/.pam_environment and then write: JAVA_HOME=/usr/local/bin/jdk1.6.0_30 PATH DEFAULT=${PATH}:${JAVA_HOME}/bin Or, you can go to ~/ .bashrc and write: export JAVA_HOME="/usr/local/bin/jdk1.6.0_30" export PATH=$PATH:$JAVA_HOME/bin