Yesterday I wrote about how to prepare Netbeans for Android development. This time some tips on how to create, run and debug projects. Something to make your work pleasurable :-).
You create Android projects just like any other. It's in Android → Android Project. Fields and their meaning:
After creating the project change "Run" settings in project options to e.g. add
-no-boot-anim to speed up staring AVD.
You could run AVD manually like so:
But Netbeans should also fire AVD so you can also just do:
Note that it will take some time to start your application even if AVD was already running. Also note that in some cases your app might not deploy on first run (e.g. because emulators start too slow and IDE will time out deployment). No worries - just run your project again when the emulator is ready.
Starting Android Emulator from command line example:
...\android-sdk\tools\emulator.exe -avd DroidName -dpi-device 150 -scale .7 -no-boot-anim
So your app run and crashed? Keep Calm And Start The LogCat. ;-)
LogCat connects to running device (emulated or real one) and shows error/info/debug and few other types of messages. This messages are either provided by the system components (usually as error messages when your app crashes) or manually (e.g. some debugging information).
You can do it from Netbeans:
Netbeans LogCat might sometimes loose connection to the device and will not be able to reconnect. That's why you should have a toolbar button.
You can also run LogCat manually. For "local" installation on Windows the full command is (just use [Windows]+R and paste this):
OR for "all users" installation:
C:\Program Files (x86)\Android\android-sdk\tools\monitor.bat
There are few methods of
Log.e... All using similar parameters:
I tend to keep the TAG variable class specific (e.g. class name prefixed with something specific to my apps), but you can have it whatever you like. This has no technical meaning. It's just something you can use for filtering LogCat. E.g. if tags are formatted as "enux.ClassName" then I can get all my messages by filtering with "enux.*" - yes, this is a RegExp.
OK, so here is a weak part of NB Android - it doesn't have a WYSIWYG editor. That said I haven't seen a good one anyway. Eclipse editor will allow you to put some widgets on the screen but to create a decent layout you will need to dig in the XML anyway.
So no WYSIWYG here, but there is a nice feature of NBAndroid that let's you preview your layout without the need to compile the whole project. Open the preview from menu: Window → Output → Android Layout Preview. It will take some time to start at first, but effects are solid. It's exactly what you will see on your device. In case the image is not visible you might try to change "Theme" (options available for Android 4.1 and above).
If you'd like some light layout editor then you might want to try DroidDraw. Not very accurate, but quick and is enough for prototyping. Just be sure allow clipboard for Java applications in Java security settings. This must be done BEFORE you start using it! Unless you want to copy the XML by re-typing it ;-).
Android native layouts are very limited if you compare them with HTML and CSS. Years of progress cannot be achieved in a day. I find it annoying when trying to achieve more complicated and flexible layouts. And remember that on Android your layout have to very flexible - there are many devices out there. This not just about stretching. If you really want to go big your layout should change with size.
You might want to try PhoneGap. All above (in terms of building projects) still apply, but you create layouts in HTML and even test in your favourite browser. That might be much easier especially if you have web-dev background. This will also give you a head start when you decide to make move to other mobile operating systems like iOS and others.
In short - YMMV :-). If you decide to go all native you will be able to make very snappy app, but every new OS you support you will need more co-workers. There are many systems out there. For most of them you need different tools and most big platforms use not only different SDK (classes), but also a completely different languages.
So basically if you have a big team - you can go native and support many platforms. Otherwise you will either have to support less platforms or use cross-platform frameworks.