While I was reading up a little on Scala recently, I found out that I might as well contribute a little while doing it. So I translated the Scala Tutorial to Norwegian since that was one of the translations missing. You can find it among the other translations on scala-lang.org or simply click on the image below to access it directly.
Here is a small tip if you are having trouble running the Android Emulator for code that calls native methods and getting an error message similar to this:
JNI WARNING: method declared to return 'Ljava/nio/ByteBuffer;' returned 'Ljava/nio/ReadWriteDirectByteBuffer;'
... ;.nativeAsBuffer ('Ljava/nio/ByteBuffer;' not found)
The simple workaround is to add the following to the onCreate method of your main activity:
ByteBuffer dummy = ByteBuffer.allocate(0); dummy = null;
This way the classloader is “forced” to load ByteBuffer. This is not needed when running on a device, only the emulator as it seems.
This post is just a repeat of my tweet yesterday, but I feel that it is easier to search it up again here than on Twitter. A good tip can never be repeated often enough anyway…
If you are setting up the development environment for Google Nexus One in Linux by following the instructions on Android Developers you will probably notice that the the device is not listed in vendor id table. One could believe that it could be the same ID as HTC since it essentially is a HTC device, but that is not so. Google has given it a vendor id of its own (’18d1′). Why it is not listed here is a mystery, but anyhow; this is how you solve it:
Add the following line to /etc/udev/rules.d/51-android.rules
(If the file does not exist, create it.)
SUBSYSTEM=="usb", SYSFS{idVendor}=="18d1", MODE="0666"
Restart udev:
sudo reload udev
Then unplug/plug the device, and you should be able to see the device by running
adb devices
Developing Android applications using NetBeans is usually as easy as stealing candy from a baby. But the last couple of days I have been struggling with an application that uses a couple of external libraries. The other developers (using Eclipse) have a couple of scripts that they run to get the .so files included in the .apk file. When I tried running the same scrips on the .apk generated from NetBeans, the application failed to start in the emulator. I nearly switched to Eclipse (god forbid), but then I saw the light again. As it turns out, NetBeans does not include the java api jar-files in the external libs in the dex-file by default which resulted in a ClassNotFoundException.
The solution is as simple as you would expect when you have used NetBeans for a while. Add the following to the build.xml file in the project root (replace the dummy values for the signjar target):
<target name="-pre-jar">
<copy todir="${build.classes.dir}">
<fileset dir="${external.libs.dir}">
<include name="*.jar"/>
</fileset>
</copy>
</target>
<target name="-post-jar">
<zip update="true" destfile="${dist.apk}">
<zipfileset dir="${external.libs.dir}" includes="*.so" prefix="lib/armeabi"/>
</zip>
<zip destfile="tmp.apk">
<zipfileset src="${dist.apk}">
<exclude name="META-INF/*.*" />
</zipfileset>
</zip>
<move file="tmp.apk" tofile="${dist.apk}" />
<signjar jar="${dist.apk}" alias="alias" storepass="secret" keypass="secret2" keystore="my_keystore"/>
</target>
You also need to add external.libs.dir=<your lib folder> to you <project root>/nbproject/project.properties file.
Now you can install the resulting .apk file using adb install or by running/debugging directly from NetBeans. Remember to follow the tip for asset-files in a previous post if you have that kind of resources.
Whenever you ask or search for help regarding Android development, you end up with some fix related to the Eclipse ADT plugin or the Android SDK tools. My intention is to fix that by repeating parts of a great tip I found at Tim Perry’s blog. It is about how to get hold of the resources placed under the /assets folder in you Android project while running your applictaion in the Emulator from NetBeans. If your application tries to access resources from the AssetManager you will get a FileNotFoundException. The reason for this is that the assets are not packaged with the .apk like it is if you package and deploy it using the SDK tools.
The solution is:
Voila! You will now be able to run, debug and step through your code as you would expect.
It is amazing what a month in South Africa does to you. Things like Twitter, Facebook and blogging becomes pretty distant… But now I have been home for a while, Sun+Oracle has been approved by EU, I have finished (almost) my kitchen renovation and celebrated yet another birthday, so it is time to get started again!
After a discussion with a colleague at a coffee break this morning, I decided to try out Google App Engine. The getting started guide is a great place to start. It gives you a great walk-through setting up the development environment and creating a sample application. Since I am no big fan of Eclipse, I installed the Google App Engine Plugin for NetBeans. After resolving a small issue regarding path settings (see solution here), it was up and running perfectly.
Next steps will be to figure out what changes that has to be made to my existing applications to be able to deploy them on app engine. Probably the server side of YouOweMe will be the first candidate. Or maybe the KanbanFX server. I haven’t decided yet…
I was not present at the conference yesterday, so this is actually my second day here, and that also explains why there were no post from yesterday. Another explanation could have been that I was lazy, but that is not the case this time… 🙂
Well, over to what this post is all about: the conference. The keynote was held by Scott Hanselman. He gave an excellent talk about effectiveness and efficiency. Some really good stuff to bring back from that speech. Will try to list some of the techniques and tools he mentioned in a later blog post.
I will also summarize the rest of the sessions I attended today very soon here…
Great conference!
The conference was opened with a keynote by Marc Lesser. He talked about how to accomplish more by doing less. It was a kind of usual opening of a technology oriented conference, but I guess a bit of zen thinking early in the morning can only do us good.
Ola Bini presented the folding language Ioke. I will definitely download this and play around with it. Hopefully, I can use it in some presentation in near future. Really cool and fun!
The next presentation I attended was Neal Ford’s presentation about XP in practice. Nothing really new there, but more a confirmation that what I feel we are doing right applies to others as well. And, more valuable, tips and techniques for how to improve on what we are doing not so right. At last a kind of nerdy way of looking at pair programming:
Continuing on the agile track, Dan North gave an excellent talk about our obsession with efficiency. The three key points to remember from his talk is:
Back to the languages track, I attended a talk by Neal Ford where he compared Groovy and JRuby. It gave me a pretty good comparison of the benefits and drawbacks of both languages.
The only session on the Java track was a disappointment. The only thing I really got from this presentation was that I could charge my netbook’s batteries. Still running OpenSolaris on it, by the way, and is generally happy with it!
Last technical presentation today was about clojure. Kind of tough thing to jump into this late in the afternoon, but the presenter, Stuart Halloway, did a great job.
In the afternoon keynote, Cameron Purdy did a comparison of Java and C++.
Overall experience from the first day of the conference is good. It is impressive that they have gathered so many international speakers. If I should pick on something, it has to be that the opening of the conference would benefit from being a little more flashy. Maybe have the opener learn his speech and practice on the English pronunciation…?
And now, it is time for mingle and beer!
A week has gone since JetBrains announced the free and open source IntelliJ IDEA Community Edition.
I have been giving it a try and is actually pretty satisfied with it. Even though I am not as familiar with all the shortcuts as I am with NetBeans, it feels comfortable. It does not differ that much. The only problem I have encountered with the default setup is the shortcut for comment/uncomment code (Shift+/). But this is mainly because I am using Swedish or Norwegian keyboard setup where the / is entered by hitting Shift+7. This was easily fixed by adding Ctrl+Shift+7 as a shortcut combination.
I could not find a live template for test methods, but it was easy to create a new one. Here is a simple example:
public void test$NAME$(){
$END$
}
I am not sure if I like the way multiple projects are handled. If you work with multiple projects in IDEA, each project is opened in a separate frame. In NetBeans you can choose to have multiple projects open in the same workspace and/or group them in project groups. It is probably just a matter of habits, but I like the flexibility to be able to decide that myself and not be forced to open every new project in a new frame.
To conclude, I really like IDEA Community Edition, an will most probably choose use it when I am working on a project where I am in no direct need of Java EE support in the IDE. Otherwise, NetBeans is still my favorite IDE. Eclipse is still out of the question as long as Maven is involved.
Despite the fact that it comes with a price tag, IntelliJ IDEA from JetBrains has since long been a very popular IDE in the Java community. The news that they now provide a free and open source community version was therefore very welcome.
If you have been reading this blog, you probably know that I am quite a big fan of NetBeans and have written quite a few comments about the areas it excels over Eclipse. I have not really tried IntelliJ IDEA yet, but now the Community Edition has been downloaded and installed. JetBrains has provided a detailed comparison between the Community and Ultimate edition.
First Impression
The first impression is that it is fast. The startup time is significantly faster than NetBeans. The editor is responsive, shortcuts and refactorings just as you expect them to be. It sure is ugly, menus and dialogs looks like some left over AWT student project hack from the 90’s, but who cares. After all we are here to code, not to enjoy the view.
Maven
The next test is to open one of my existing multi-module maven projects. Just as with NetBeans, it is just to select the root pom.xml file and open it. All sub-modules and dependencies are resolved just as expected. It scatters a lot of .ipr, .iwl and .iml files all over the place, but I can live with that as long as it updates them with changes from the pom.xml files.
When I check the Module Settings, it seems like the compiler output is set to /classes and not /target as normally by the maven convention. But when i build the project, it uses the maven configuration and puts the compiled classes under target. Why? Well, as long as it works it is okay with me…
Web and Enterprise
As the comparison table shows, there is no support for any web, mobile or enterprise frameworks in the Community edition. Nor are there support for application servers. You would have to buy the Ultimate edition for this. Fair enough, they have to make money somewhere.
Conclusion
The Community Edition of IntelliJ IDEA is the perfect choice if you are building a simple java application. It lacks support for development using web, mobile or enterprise technologies. If you want an IDE that is comparable to for example Eclipse Gallileo or NetBeans you would have to go for the Ultimate Edition. In my view NetBeans is the better choice.
Disclaimer: I Â have only scratched the surface here and will continue explore the Community Edition. My opinions may change as I go…