TamsIJungle

Traditionally, integrated development environments were file oriented – if you edited code, you edited it on a file-by-file basis.

Code Bubbles is an experimental Java IDE which goes a different way. In it, functions are the elemental parts of an application: you edit code on a per-function level, and can open calling and called functions easily.

A video showing the concept is below – set it to a lower resolution on a slower machine:

This one is for all registered Apple developers – the beta 4 of iPhone SDK 3.2 has just been released.

As usual, non-registered members see but this:

Long-term followers of TamsIJungle will likely remember Unity3D – the company released a generic 3D engine for the iPhone some time ago. It has just been updated…

Version 1.6 adds the following features:

…

Reduced Binary Application Size
When building your games for the iPhone or iPod touch they will now be smaller than ever. Build sizes may be reduced by up to 25%. This reduced application size will improve the over the air downloading experience as well as offer reduced loading times and a smaller memory footprint when running.

Updated .NET 2.1 Support
We updated Unity iPhone to include a newer version of Mono in order to offer .NET 2.1 support on the iPhone. This is exciting news as it allows developers to use even more 3rd party libraries as well as generics when creating their iPhone applications with Unity. What’s also exciting is that it also allows even easier porting of Unity 2.6 desktop/web projects over to the iPhone.

Multiplayer Networking Support
Unity iPhone now supports Unity’s built-in networking features, thus allowing developers to create multiplayer experiences like never before. This support includes the ability to offer multiplayer games over Wi-Fi or the 3G/3GS networks. This is most certainly an exciting addition to the Unity iPhone toolset.
…

Further information can be had at the URL below:
http://unity3d.com/unity/whats-new/iphone-1.6

AdMob has recently extended its monetization service to webOS and iPhone applications. This means that they can now collect more information about the users of these platforms.

Some interesting tidbits are below:

Further information can be had below – it’s a PDF file:
http://metrics.admob.com/wp-content/uploads/2010/02/AdMob-Mobile-Metrics-Jan-10.pdf

Long-term followers of Tamoggemon know that the products usually have a minimized interface – this is due to fanatic tap counting in the UI design department. However, tap counting is but part of a successful mobile UI – you usually also need to adhere to common design patterns.

So far, no collection of design patterns for mobile applications has been published in book form. However, the design4mobile wiki is a more than adequate replacement:

Hit the link below to find out more:
http://patterns.design4mobile.com/index.php/Main_Page

Amazon has just sent out a few invites to developers who indicated “interest” in the Kindle – it offered a further form, offering you to “apply for a place” in the Kindle developer test program.

Amazon has now posted an FAQ for Kindle developers – the most relevant questions are below:

# What APIs are available to me in the KDK?
The KDK is comprised of two sets of APIs:

* Java version 1.4 Personal Basis Profile (PBP) APIs for mobile devices.
PBP JavaDocs can be found at http://java.sun.com/javame/reference/apis/jsr217/.
* Kindle custom APIs which complement the PBP APIs and provide UI components, JSON and XML parsers, HTTP and HTTPS networking, secure storage, and other features. Other APIs like audio and dictionary access will be available in a future release of the KDK.
KDK JavaDocs can be found at http://kdk-javadocs.s3.amazonaws.com/index.html.

# I’ve already built a Java Micro Edition (J2ME) application. Can I port it to Kindle?
Yes. You should be able to modify existing Java applets and J2ME software to run on Kindle.

…

As of now, Tamoggemon has not been accepted – stay tuned!

Apple’s App Store is unique in two aspects: it is, first of all, insanely successful – and does not allow time-limited trial versions. These two aspects have led quite a few to question the value of free trials – unfortunately, getting data out of developers has been all but easy.

Todd A. Sherman from Smart Box Design (a games company) now shares the following – according to him, trial versions don’t really pay out in the “nice new world”:

I did an analysis of the best selling Word games and compared their numbers and ratings against their free version. For the Word category it did not seem to make a huge difference if you had a free version or not. We got a huge bump in downloads from our Free version, thousands and thousands of downloads, but only saw a modest change in sales. However, getting on people’s mind space was worth it for us.

We are, of course, looking at an individual opinion here. However, the information I have received from other parties sounded similar…

Stores like Apple’s tempt developers to ask friends and users to screw around with the ratings system – I think that everybody does it to some extent. However, overdoing it is unhealthy: which is what a developer called molinker just found out the hard way.

iphoneography reports the following:

…

Following on from my post last Saturday (courtesy of SCW) regarding Molinker and their involvement in the ratings and reviews scam of their apps in the US AppStore, I am please to confirm that this developer has been expelled from the AppStore.

Myself and SCW contacted Apple’s Phil Schiller regarding this scam, and today following a follow up email from both of us, Phil Schiller replied confirming “Yes, this developer’s apps have been removed from the App Store and their ratings no longer appear either.”

…

From my point of view, we’re looking at a classic case of “one bridge too far” here. If the developer wouldn’t have gotten the media on his neck, he probably still would be doing what he did.

The core lesson here is modesty…

Keeping data synchronized between various mobile devices can become quite a chore – newcomers usually fail at getting a working solution up, and books on the topic tend to be extremely thick.

Kee Nethery from kagi.com has graciously given us permission to repost the following interesting bit of prose which he posted to the pef-talk, which is a closed-door discussion forum for mobile developers:

We don’t have a wireless sync situation but incremental updates is
something that we have done in various systems that interact with
each other plus I’ve seen some good ideas on this elsewhere.

First, Apple has a notification service for the iPhone. The idea is
that the client does not bother the server until the server sends
it a
change notice. And the client does not notice the change notice until
a user decides they should run the application. This means that there
is only one iPhone app that is always polling the master update
thingy
that all services share and when it gets a change notice, it sets a
value (in their case it alters the icon on the GUI so that the human
sees there is an update). When the app gets launched by the human, it
sees the altered icon and goes and fetches it’s data from it’s server
and clears the icon alteration (or something like that). Thus, the
app
only does updates when the user triggers it to run.

This is a good system in that instead of every app trying to run it’s
own background process to keep itself up to date, only one app does
this and between updates it sleeps. So the processor usage and
network
traffic is small no matter how many apps want to keep themselves
updated.

Moral of the story, it would be good if you could use some built in
receiver (SMS maybe?). If not SMS, perhaps sync when the app first
launches and then ask the user how frequently they want the app to
wake the device and attempt a sync (reminding them that this will
affect battery life). You could have something like a sync every
minute for the next hour button. Try not to build code that always is
pinging the server. That would use up the battery especially when
most
syncs will probably have no changes to deal with.

Second, on the server side, every row in the database should
contain a
lastModifiedDate value that gets set each time the row is changed. We
use database triggers to keep that value updated. Then your sync
routine is very easy. Something like:

select * from thetable where lastModifiedDate >=
theMostRecentLastModifiedDateStoredLocally

And if in the first sync you are grabbing way too much data for a
single select (assuming you have a bunch of data) do it in manageable
increments.

set rowcount 100
select * from thetable where lastModifiedDate >=
theMostRecentLastModifiedDateStoredLocally
order by lastModifiedDate ascending
set rowcount 0

So that it gives you the oldest stuff in small chunks until you eat
up
all the changes.

Note, always have unique row IDs and always use the data you get to
replace existing rows. This allows the server to send you overlap
data
(data you got at the tail end of the last query) to make sure you
don’t miss anything.

Also note, theMostRecentLastModifiedDateStoredLocally is a date time
value but DO NOT use your local time on the device. Treat
theMostRecentLastModifiedDateStoredLocally as some incrementing value
and not as a date time. It looks like a date and time that you could
derive from your local clock, it is not. This prevents you from
getting messed up when daylight savings time changes or when the time
zone changes. We tend to keep this value as a separate data value
that
gets updated with each update pull from the server (so that we don’t
have to scan the local data to get the most recent value).

Third, if the data changes are non-stop such that even as fast as you
can grab them, new changes are getting put into the database, and you
really don’t need to have it continually get updates every second as
they occur, you can do something like, if the number of rows returned
is less than some number (lets say 5) then consider yourself done and
wait until your next update time period before grabbing more rows.

Fourth, you can lessen the load on the database by putting a proxy
service between the client doing the above SQL and the database. For
example, in the rowcount example you could have the client send
something like

getChanges(thetable,theMostRecentLastModifiedDateStoredLocally)

and the server could cache sets of data, perhaps 10 minutes worth of
changes, in a set of cache files with file names like
YYYYMMDDHHMM.txt
and it could just feed you back the files that are in the proper date
range (oldest gets sent first) and then for the last set of data, get
that from the database.

Finally, the goal is to find ways to minimize the communication
between the client and the server and to have the user be satisfied
with the update frequency.

A big thank-you to Kee…

Nokia’s Ovi Store has had a progress bar on reviews for some time – don’t ask me what motivated Apple to leave developers in the dark about the approval process.

Gizmodo now shares the image below:

All I can say here is: it was about time…