Shin: Almost There

Well it’s 2am. Good time to put a post on how this project is going: — good!

Considering we are maybe 13 hours from deadline, I think we’re at a pretty good area.

Just adding a little change here and there – I’ll need to confirm with douglas though;

Getting the presentation ready as well – it looks like the presentation will only be 8 minutes and the majority of the time (10 minutes) will be used for Q & A … so everyone; get ready!

Some fairly unexciting demos

So I’ve half gone about implementing the ui stuff, albeit in flash, though I’ve been weary to avoid any flash specific code, such as MotionTweens and whatnot, so it can be easily ported to android.

Attempted multiple methods for getting the smooth motion, one which created much delay was the idea of using fixed positions for the items and doing matrix transforms on points to create the motion. Just like my ex-girlfriend, it became unweildly quickly, difficult to understand and maintain. It was hard to break ties because I’d been working at the problems for so long, but eventually I had to dump it and replace with something fresh. (Not only that. but I copied the wrong files to my laptop — Good one — so I had to work on something different on the train.)

New method makes more sense, should have done it in the first place, using trig equations (sin) to make the transforms.

Benefit of using flash at this point is that I can get down to the business of how the stuff will work without worrying about the sdk… at this point.

After I implemented the scroller, I thought it’s probably better to simply use a paginated system (I think it was discussed at some point), where the user simply flicks in a direction and it scrolls X units that way.
Or maybe some combination of both.

Flick Pros
Control. You have control,  no change in experience as number of nodes increases.  Move a consistent number of nodes each time

Flick Cons
Scaling. Issue is that you may need to do much flicking to access ends of lists.

Scroll Pros
Easy to move about your data. Inuitive, Sexy & Fun (like a good girlfriend?).

Scroll Cons
Scaling. If there is a dumpload of nodes, it may become hard to control, as movements will scroll the nodes too fast.

Using a circular linked list structure could help excessive movement in both cases, though it could increase confusion as we aren’t really uesd to scrolling infinitely, but it could work well… need to remove the scroll block, and replace with a single line that represents the loopback point.

Maybe a better way to do it is:

Tap on Scroll Bar:
jog in the L/R direction.

Flick on Scroll Bar:
Accelerate the scroll bar as if it actually had weight… like flicking a bike wheel to keep it spinning.

Only problem with this is that you can’t ‘instantly’ move to the location you want if you know roughly where it is.  Currently, if you know your item is 80% towards the end, you’d tap 80% along the scrollbar and you’re there.

Maybe to combine all of them in the best way:

Flick:
Accelerate in direction of flick (x,y)

Single tap up (no flick):
slight ‘jog’ in direction. Scrollbar split like so:

| -11 |       -5       |       + 5        | +11 |

ie, we move double the number of items if we hit the far extremities. Number of items in this example is assuming 6 is the number of items viewed on screen, so with each tap we move 5 nodes, keeping one single item from the previous ‘group’ for ‘context’.

Double Yap:
move directly to that location on the scrollbar.

Once accelleration drops below a certain level, the nodes should ‘snap’ into designated positions.

We also need to think about our ‘paradigm’. We’re working with ‘ideas’ so I’m thinking we should do things like: To delete a node you drag it to the scrap pile, or you burn it, as you would to a ‘real’ idea.

Mockups
(no paradigm stuff yet, just ideas):

Rough Demos

http://timoxley.com/demo

http://timoxley.com/demo?demo=2

http://timoxley.com/demo?demo=3
Demo 2, just playing around with having the list move along an arc.
Need to rework code so they can move in a circle.

I’ll add to these demos/mockups after Monday/Tuesday, but this is what I was thinking, roughly for the scrolling business.

How to close applications on android

I was confused as to how to close the browser/other apps on Android, and found an interesting feature request regarding closing applications on Android. Apparently:

• Apps are never terminated manually (I.E. No kill-task button ala Windows Task Manager or OSX’s Force Quit). Applications have to terminate themselves.
• Most applications will quit when you hit the back button, but…
• …The browser app is an exception. It does not quit when you use the back button. Instead it ‘pauses’.
• The Process Explorer App can be used to view running processes. This is not the same as holding down the “Home” button, which simply displays a list of recently used apps, regardless of whether they are still running.

Android is intelligent in the way it handles background app resources. Once an app is paused in the background it uses minimal resources (so long as it isn’t keeping GPS connections open, or actually doing something). As applications need more CPU/memory, android increases their allocation, and shuts down processes as it deems necessary.

From the CloseEverything Wiki

When an application closes in Android, it saves its state so that next time it starts up it can restore its state and look like it was never closed at all. Also, even when applications are closed, they still appear in the task manager (when you press and hold the Home button).

The Application CloseEverything exploits the way Android shuts down apps to provide a tool for closing down apps.

From a Mobile Apps Today post:

[CloseEverything] floods the memory of your device to close out all other running apps. This will shut down all background services for Android as well, but those actually pop back up when the app is finished.

Interesting. I do find it strange that they opted for no standard ‘X’ Close button in the UI somewhere, instead leaving how that stuff works up to the developer… hm.

Android ADT & Eclipse in Ubuntu: Check System Requirements

Don’t be fooled into thinking that if you keep your packages up-to-date you don’t need to verify system requirements. Unfortunately, packages do take time to get fed into canonical. Always check system requirements and download latest versions directly from the vendor, to save yourself the headaches of following instructions that don’t quite work, leaving you wondering: is it me? the computer? maybe the instructions are bad (wouldn’t be the first time)?

The Android ADT system requirements state minimum Eclipse version is 3.3, but be aware that the newest version of Eclipse provided by the Ubuntu package manager is 3.2, and that Eclipse plugins will not explicitly complain if they are loaded on the wrong version, they’ll just attempt to work and potentially behave unexpectedly.

When trying to follow the ADT installation instructions, the ADT plugin causes all sorts of trouble using Eclipse 3.2. For example, you’ll get the following error when trying to access:
Window -> Preferences -> Android

Plug-in com.android.ide.eclipse.adt was unable to load class com.android.ide.eclipse.adt.preferences.AndroidPreferencePage.

You may come across the following error in addition to the first one:

Could not open the selected VM debug port (8700). Make sure you do not have another version of the DDMS or of the eclipse plugin running. If it’s being used by something else, choose a new port number in the preferences.

Searching forums for this error etc, gives mixed ‘answers’, including check firewall settings, do not use subversive, install Sun VM, ‘Check your JDK‘, while the solution is to simply download the latest version of Eclipse IDE for Java Developers and use that.