Recently I found myself wanting to inspect what was in the application database outside of the mobile application I was working on, which as usual lead me to search for a solution on DuckDuckGo.

I found a great link here, which basically says:

1. Download and install SQLite command line tools if necessary (OSX comes with one).
2. Find the SQLite file you want to inspect
3. Run the command to open the database and inspect it:

sqlite3 /Users/<username>/Library/Developer/CoreSimulator/Devices/<Simulator device ID>/data/Containers/Data/Application/<App id>/Library/Private\ Documents/_alloy_.sql 
sqlite> .tables 
user order item 
sqlite> .schema user 
CREATE TABLE user (id INETGER PRIMARY KEY, uname TEXT, fname TEXT, lname TEXT); 
sqlite>select * from user; 
1|jsmith|John|Smith

read more

Open terminal and do the following:

[korey@localhost ~]$ cd /Library/Java/JavaVirtualMachines
[korey@localhost /Library/Java/JavaVirtualMachines]$ ls -al

This will give you a list of JDKs that you have installed. To set the default java version to 1.8.0_131 for example, use the following command:

[korey@localhost ~]$ /usr/libexec/java_home -v 1.8.0_131 --exec javac -version

Related link read more

After updating the Appcelerator CLI, my build started failing. The log message was not very helpful, but Google was and it lead me to this link. The gist of it is here:

result from /build-verify=> {"success":false,"error":"invalid request","code":"com.appcelerator.security.invalid.session"}, err=null

The answer, perform the following

 
[korey@localhost ~]$ appc logout                                                                                                                                                                                                                                                
Appcelerator Command-Line Interface, version 6.2.0
Copyright (c) 2014-2017, Appcelerator, Inc.  All Rights Reserved.


*** Logged Out ***

[korey@localhost ~]$ appc login                                                                                                                                                                                                                                                 
Appcelerator Command-Line Interface, version 6.2.0
Copyright (c) 2014-2017, Appcelerator, Inc.  All Rights Reserved.

Appcelerator Login required to continue ...

? Appcelerator ID: me@company.com
? Password: *********
Generating Developer Certificate and Private/Public Keys...
me@company.com logged into organization company.com [100011118]

read more

Here is a little tip for customizing apache on OSX. The first thing you have to do is turn on Web Sharing in your System Preferences. This will start the local Apache server and you can access it by going to http://localhost. From here, you can start modifying it to your will. Apache customization is a big topic and you can find all you need on the Apache website. Here are a few tips:

• Apache is installed at: /etc/apache2
• Apache config is at: /etc/apach2/httpd.conf
• Apache user config is at: /etc/apach2/users/<username>.conf
• Apache extra config is at: /etc/apach2/extra/*.conf
• You can customize your own virtual server by modifying: /etc/apach2/users/<username>.conf
• You can start/stop Apache by:
  • Enabling/disabling Web Sharing in System Preferences
  • running the following in terminal:

    sudo apachectl 

In order for you to get going and have a user directory, you will need to make sure the following is done.

• Create folder to host your files (e.g. /Users/<my_username>/Sites/)
• Create an index file in the above folder with a message so you know when it is working.
• In /etc/apach2/httpd.conf, make sure:
  • userdir_module is loaded (i.e. not commented out).
    LoadModule userdir_module libexec/apache2/mod_userdir.so
  • httpd-userdir.conf is included.
    Include /etc/apache2/extra/httpd-userdir.conf
• In /etc/apache2/extra/httpd-userdir.conf, make sure that user configuration files are included.
  Include /private/etc/apache2/users/*.conf
• In /etc/apache2/users, make sure to create a user file for yourself (note: you will have to use sudo to make sure permissions on the file are set to 644 and owned by root:wheel).
  /etc/apache2/users/<my_username>.conf
  Contents:
  

  <Directory "/Users/<my_username>/Sites/">
    Options Indexes MultiViews
    AllowOverride All
    Require all granted
    DirectoryIndex index.html
  </Directory>

At this point you can should be able to start (or restart) Apache and test your setup. http://localhost/~<my_username> read more

One of my recent adventures into NodeJS has led me down the path of MEAN and reading various articles on that, I came across various Terminal alternatives and enhancements. I know, I know, I am late to the party, but when I saw FishShell, I was sold. Then I saw Powerline and liked that too, so here is how to set these up. First thing is to make sure you have Homebrew installed. Then you can install fish simply by running the following command:

[korey@localhost ~]$ brew install fish

Now that fish is installed, you will have a few options in making it your default shell. Homebrew provides instructions already, but I just wanted it on my account for Terminal, so I changed the shell command in Terminal’s preferences. Great, now you can use fish anytime you open terminal, but what about getting Powerline setup? The instructions are here, but I will include what I did here for completeness.

[korey@localhost ~]$ brew install python
[korey@localhost ~]$ pip install powerline-status

The next step is to install the patched fonts so your prompt will not have strange characters on it. For this part, you need to download the patched fonts zip from github, and then run the install.sh script included there. The last step here is equally important; you should change the font used by your selected terminal profile to one of the fonts for Powerline. Now that Powerline is installed, you will need to update your Fish config to load it.

[korey@localhost ~]$ vi ~/.config/fish/config.fish
# source autojump
[ -f /usr/local/share/autojump/autojump.fish ]; and . /usr/local/share/autojump/autojump.fish

#source powerline
set fish_function_path $fish_function_path "/usr/local/lib/python2.7/site-packages/powerline/bindings/fish"
powerline-setup

My last step was to install auto jump, which is another great tool and you can see that it has also been included in the above listing in my Fish config.

[korey@localhost ~]$ brew install autojump

You should now end up with a autocomplete terminal similar to this: read more

Installing MongoDB on OS X is an easy task. However, if you want the service to start each time your computer is restarted, some additional effort is required. The easiest way to get MongoDB installers is to use Homebrew.

[korey@localhost ~]$ brew install mongodb

At this point MongoDB is installed. To start it manually, first create the location where the DB will be stored (default is /data/db):

[korey@localhost ~]$ mkdir /data/db
[korey@localhost ~]$ mongd

Note that the user running mongod needs to have write access to the DB folder. The downside here is that the DB needs to be started manually each time and it will run as your userid. In order to automatically start the service, it is necessary to create a LaunchDaemon which will allow the service to start as soon as the computer starts.

1. The first step is to create a service account so the service does not run as root. 2. Next, is to create a proper location for the log and database location:

[korey@localhost ~]$ sudo mkdir -p /var/lib/mongodb
[korey@localhost ~]$ sudo mkdir -p /var/log/mongo
[korey@localhost ~]$ sudo chown -R _mongo:_mongo /var/lib/mongodb
[korey@localhost ~]$ sudo chown -R _mongo:_mongo /var/log/mongo

3. Now that we have an account and location, it is time to create the daemon plist file:

  
    Label
    org.mongo.mongod
    ProgramArguments
    
      /usr/local/bin/mongod
      --dbpath
      /var/lib/mongodb/
      --logpath
      /var/log/mongo/mongodb.log
    
    KeepAlive
    
    UserName
    _mongo
    GroupName
    _mongo    
  

Store this file at: /Library/LaunchDaemons and name it: org.mongo.mongod.plist.

Now you can start and stop the service without having to restart your computer by using the following commands:

[korey@localhost ~]$ sudo launchctl load /Library/LaunchDaemons/org.mongo.mongod.plist
[korey@localhost ~]$ sudo launchctl unload /Library/LaunchDaemons/org.mongo.mongod.plist

read more

Creating service users on OS X is not as straight forward as doing so on Linux system.  For starters, the useradd command is not available. So in order to perform the same action on OS X, open a terminal window and run the following commands. For this example, I will create a group and user in order to run MongoDB.

[korey@localhost ~]$ sudo dscl . -list /Users UniqueID
_amavisd                83
_appleevents            55
_appowner               87
_appserver              79
_ard                    67
_assetcache             235
_astris                 245
_atsserver              97
_avbdeviced             229
_calendar               93
_ces                    32
_clamav                 82
_coreaudiod             202
_coremediaiod           236
_cvmsroot               212
....

The above command lists all the current users along with their UID. This is necessary so that we can pick an unused ID below 500 (UIDs above 500 are for normal users). You can run the same command with /Groups instead of /Users to get a list of groups. First, lets create a group for the users with the same name:

[korey@localhost ~]$ sudo dscl . -create /Groups/_mongo gid 300
[korey@localhost ~]$ sudo dscl . -create /Groups/_mongo RealName "Mongo DB Server Group"
[korey@localhost ~]$ sudo dscl . -create /Groups/_mongo passwd "*"

As you can see the group ID is set to 300, and the password is set to “*”. This is a special password not to allow logins as that group of user. I am not certain if this is necessary, but looking at other similar groups on OS X, it seems to be the right way to do this. Now, lets create the user and make sure that it will not show up as a user on the login screen:

[korey@localhost ~]$ sudo dscl . -create /Users/_mongo
[korey@localhost ~]$ sudo dscl . -create /Users/_mongo uid 300
[korey@localhost ~]$ sudo dscl . -create /Users/_mongo gid 300
[korey@localhost ~]$ sudo dscl . -create /Users/_mongo NFSHomeDirectory /var/empty
[korey@localhost ~]$ sudo dscl . -create /Users/_mongo UserShell /usr/bin/false
[korey@localhost ~]$ sudo dscl . -create /Users/_mongo RealName "Mongo DB Server"
[korey@localhost ~]$ sudo dscl . -create /Users/_mongo passwd "*"

At this point, the service account is created, and its primary group set to the one we just created. Setting the shell and home folders are necessary to make sure that the account does not show up on the login screen and to ensure that even if someone does login as that user, they will not have access to anything. Once again, the account password here is set to “*” in order to not allow logins. If you look at /etc/passwd on your OS X machine, you’ll notice that most service accounts are listed in there, but the above account is not. I am not sure if this will be problematic over the long term, but for all intents and purposes, the service account works as expected. Naturally, I searched a good while before I came up with the above command set and here are some links that helped me:

• http://ss64.com/osx/dscl.html
• http://linuxtoosx.blogspot.ca/2011/06/create-user-account-from-os-x-command.html
• http://kb.ucla.edu/articles/description-and-guidelines-on-creating-system-service-agent-accounts-on-mac-os-x-tiger

read more

In order to have a fully regression tested application, it is necessary to have an automated build process to ensure all checkins are validated nightly ( or whatever your schedule is). This is a simple task for most Java projects, however you may run into some issues with Android that I point out here.

• If you started your project from Eclipse, you may not have the Ant build file and supporting properties file in your project
• If you want to sign your application with a key, the default build keeps prompting you for the keystore password

Both of these are relatively easy to over come and here is a great article on StackOverflow. My only goal here is capture it all in one place.

Environment Setup

The first thing to do, is to make sure that your android SDK folder is on your path. In order to do that, just update your local .bash_profile in your home folder to include the following paths:

#!/bin/sh

export PATH=$PATH:$HOME:$HOME/Documents/Development/android-sdk-macosx/tools:\
$HOME/Documents/Development/android-sdk-macosx/platform-tools

export ANDROID_HOME=/Users/Kouroche/Documents/Development/android-sdk-macosx

Note the \ in the first export command. It is there to split the command over two lines, but you don’t need that in there. This will not only add the Android SDK to your path, but also define ANDROID_HOME which is used by the build file (more on that later).

At this point, you will either have to logout and login again, or source .bash_profile to make sure the changes took effect. To verify, run the following command from your home folder:

$ android list targets

Build files

In order to add the build files to your project, you can either create a new project from the command line and copy those build files to your project, or you could update you project from the command line to add in the build files.

Creating a new project

In order to create a new project from the command line, run the following command:

$ android create project --target  --name MyFirstApp \
--path /MyApp --activity MainActivity \
--package com.acme.myapp

The app name nor the package matter. The only thing you may want to match to your current application is the <target-id>.

Once the project is created, copy over the following files to the root of your own project and then delete this app folder.

• ant.properties – This is where you store your project specific properties for Ant
• build.xml – This is the generic build file provided by the Android SDK and will most likely not need changing
• local.properties – This file contains the path to your SDK, but I prefer not to copy it over since it may get checked in by mistake.
• progaurd-project.txt – This file contains ProGaurd rules if you choose to obfuscate your code, and more can be found here about that.
• project.properties – This file contains the target for your project and is most likely already part of your project.

Updating your existing project

This is probably your best bet since it is less of a hack and should add the same set of files to your project.

$ android update project --name  --target  \
--path 

Once again, make sure to use the same <target-id>

Customizing the build

Now that you can use Ant to build your project, you may want to customize the build process to meet your needs. For example, I always include a build ID somewhere in the application so users can report which build they are on when reporting issues, or you may want your release build to point to a different backend server than your debug build. In any case, the Android SDK makes this also very easy. Looking at the build file, it optionally imports a custom_rules.xml file that you can create in your project root folder to hook into the build process. The build file even lists out the targets for your to include. Here is a sample one I created:

What this does, is to update the build ID in my constants class, and also update the backend server my app talks to depending on whether it is a release build or not.

Signing the app

One of the issues I mentioned early on, for the need to have build automation, was having to provide a password each time the app needed to be signed. Well, the key to solving this problem is the ant.properties file which includes your project specific properties. Unfortunately, i have not found a way around having to include your password in plaintext in some form or fashion so that it can be used, but if your an individual or have a designated build person or machine, you can lock the file down pretty good. So, to get back to the issue at hand, include the following four lines in your ant.properties file and you are good to go:

 key.store=
 key.store.password=
 key.alias=
 key.alias.password=

If you have been building with Eclipse for while and don’t recall your keystore alias, an easy way is to go through the export process in Eclipse to release the app and see what the keystore alias is.

The build command

OK, so now that it is all set, the easy part is building the application. You can run either of the following commands to build the app for debug or release respectively.

$ ant debug
or
$ ant release

Good luck. read more

I found this on stack overflow, so I am just recapturing here since i found it so useful. First, unzip the APK and extract the file /META-INF/ANDROID_.RSA (this file may also be CERT.RSA, but there should only be one .RSA file). Then issue this command:

     keytool -printcert -file ANDROID_.RSA

You will get certificate fingerprints like this:

     MD5:  B3:4F:BE:07:AA:78:24:DC:CA:92:36:FF:AE:8C:17:DB
     SHA1: 16:59:E7:E3:0C:AA:7A:0D:F2:0D:05:20:12:A8:85:0B:32:C5:4F:68
     Signature algorithm name: SHA1withRSA

Then use the keytool again to print out all the aliases of your signing keystore:

     keytool -list -keystore my-signing-key.keystore

You will get a list of aliases and their certificate fingerprint:

     android_key, Jan 23, 2010, PrivateKeyEntry,
     Certificate fingerprint (MD5): B3:4F:BE:07:AA:78:24:DC:CA:92:36:FF:AE:8C:17:DB

Voila! we can now determined the apk has been signed with this keystore, and with the alias ‘android_key’. Keytool is part of Java, so make sure your PATH has Java installation dir in it. read more

There are two more players that are trying to enter the mobile OS space: Firefox, and Ubuntu. While the latter is making the move for more native applications to run faster on phones, the former is trying to take page out of WebOS’ playbook by going the pure HTML5 route. I had a chance to install the Firefox OS recently on a Nexus S and it fairs well but still has a long way to go before it is ready for prime time. Here are some links to get you started if you want to try them.

1. Take a backup of your phone.  Since i had a Google Phone, I was not worried too much since Google provides the factory images here (so long as you know your model).
2. Go to the Firefox link here and get started.

Firefox’s instructions are pretty straight forward and everything has been automated to the point that I just fast paced through the commands and ran those (on a Mac).  the process does take sometime, specially if you do not have a fast PC, and it downloads the Android SDK and tools to boot.  My only issue was finding the google page to restore my phone since the Firefox OS is still not on par with iOS or even Android, and I needed my phone. Ubuntu on the other has is making more calculated decisions and only providing installers for mutli-core devices. As they say, “You only get one chance to make a first impression,” so it better be good.  Here are some instructions to install it on the Nexus 7. read more