It’s over

Well that’s the end of that. I for one am glad to be able to do something different with my waking moments than code Java. I’m disappointed with how it all went yesterday. The problem was quite obviously the feature explosion that happened recently that we didn’t have time to test and get working properly. Those extra few weeks at the beginning are looking particularly succulent now. So would another team member.

I still feel as though we had the best idea, and that ours was the hardest to do, from completely building a custom interface, animating it, building really cool gesture controls, and having to pull data from a variety of sources, especially given the lack of api development by Google in the calendar field.

Oh well onwards to ADC, where the prize money is better and we have more time to flesh out our idea and get it working.

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!

About to present my Seminar

And no-one’s here. Is this a good thing? Probably. Now if there’s no discussion it’s not my fault. I prepared something, it’s probably too short and to lecturery. Hopefully it meets the criteria sufficiently that I don’t fail the subject.

Ok, went reasonably well. Audience got much bigger, must have been excited. Didn’t generate a lot of discussion about mobile security but probably did the job.

Now that this is over I can actually continue to do some work on the actual coding. There’s still plenty to do. Have to fix animations, and figure out how to manipulate the calendar from the phone. I don’t have any other subjects to work, so I guess, I’ll get it done. Of course this assumes it’s actually possible. Otherwise I might have to edit the android sdk. I hope it doesn’t come to that as I’ve been having enough trouble just checking it out.

Faster start up of the Android Emulator

First of all, you may wish to have a look here, and setup a memory card in your project directory called my128MbCard if you want to use any of the scripts or have a look at the TraceViews of our application.

Starting the emulator from eclipse to the Android Home Screen: 1 minute 50 seconds+

Starting the emulator from the command line to the Android Home Screen: ~30 seconds.
(using this command: emulator -avd 1.5sdcard -skin G1 -sdcard my128MbCard)

That’s over 3 times faster!

Anyways give it a crack, YMMV.

I’ll be uploading a few shell scripts to the github repository that:

• Start the emulator
• Install the application to the emulator or device and then runs it
• Uninstall the application from the emulator or device

Note: If you deploy using Eclipse, then uninstall using the command line, then try to deploy again from eclipse, you may encounter the situation where eclipse thinks the application is installed, but it isn’t, so you will enjoy the following infinite loop:

[blah] Application already deployed. No need to reinstall.
[blah] Starting activity com.candlelightproject.lifemap.LifeMap on device
[blah] ActivityManager: Starting: Intent { comp={com.candlelightproject.lifemap/com.candlelightproject.lifemap.LifeMap} }
[blaht] New package not yet registered with the system. Waiting 3 seconds before next attempt.

Simply do a Project->Clean in eclipse, and the deploy will work again.

I’m going to have a play around with TraceView and see if there are any places we can look to optimise in our current application as it stands.

Animation

Working this week on developing animations for our app has an been an interesting proposition. It seems to be impossible to specify your own animations by repainting the canvas, the way I’ve done it in the past with jpanels. Instead android provides a number of animation classes that all seem behave a bit strange, especially in the context of our app. Doing simple 2D graphics with fancy transitions doesn’t seem to be what these android’s animations were made for.

There certainly wasn’t anything for moving an object around a circle until I got around to extending the animation class. But even after writing my own animation, and it seems to do the right thing, it still seems to be offsetting my objects and it never resizes them properly. This is probably because animations manipulate the view’s canvas after it’s been drawn instead of resizing and moving the view itself and hence 9-patches aren’t resized properly.

Oh well, considering the progress I’ve made so far with not too much work, I’m sure I can resolve the jerkiness that takes place at the end of a transition, as it goes from the scaled, translated canvas to a resized, moved view. The obvious goal is to get the two be identical before the animation finishes. I don’t think that will be too hard.

Mid Semester Review

Overall, I feel our mid semester review went pretty well. I wonder if trying to stick to the time limit hurt us, but I imagine the only thing that let us down, was our lack of actually research into what was out there. Given the quick switch we had to make about four weeks in, we lacked the time that the other groups used to do more research.

Saying that, I don’t think it will hurt the quality of our final product, but it would have been nice to have been able to answer questions with confidence that this indeed would be useful app for people and that it is original. I’m pretty confident of both factors though.

Kim’s question about whether there interest for such an app, did make me think though. Especially since I had dismissed both of the other apps as being irrelevant to me personally. Although remote access to TiVo is pretty cool.

I wonder if I’m the only one who thought the guest lecturer’s company has an evil business plan.

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.

Seminars?

They just seem so really weird. Are they a chance for each student to give a lecture? Why do they keep asking questions when they already have ideas and then act like they want our input. It seems so hard to know how one is supposed to present it. Should we just read out an article we found published on the web, or should we talk for a few minutes and then ask everyone to tells us what they think?

I feel that a seminar should be more like COMP3301, where we were given links to a number of articles about a topic prior to the seminar and then we would discuss in groups the topic. Then someone from each group would present. This way no one in particular was singled out as an authority and everyone got a reasonable chance to be heard. Perhaps if there was a little more structure I would have a better idea, but I’m not sure. It’s silly to second guess, but the seminars are always a little uncomfortable.

Accessing Calendar Data in Android SDK v1.1r1

Been having some trouble accessing the calendar data that will be stored on the phone for users of the Calendar application.

The root cause of this trouble is:

• The Android v 1.1r1 SDK does not include the Calendar application or CalendarProvider (the preferred method of requesting information from another application on an Android phone.

Now, Android applications basically store their data as SQLite3 databases on the phone, so I attempted to pull my calendar database from my Android Dev Phone 1.  Turns out that it is a protected file and cannot be copied off the phone … So I tried to build and put the Calendar application and CalendarProvider functionality into the current Android v1.1r1 SDK, which almost seemed like it would work, until the Google Sign In utility hanged, so it wasn’t possible to setup the Calendar application at all (I was ultimately left with an empty calendar database).

So at this stage I’m left with a few options:

1. Poke around the empty Calendar SQLite3 database, and use raw SQL commands to potentially create new calendars, events etc.
2. Somehow get the current cupcake or master branch to compile with the Calendar application and the CalendarProvider functionality.  This would be ideal as using the CalendarProvider should hopefully make the end code more easily adaptable to any future changes in the source tree.
3. Use the XML based Google Data API to create XML requests to be sent over HTTP to perform the desired functionality.  I’ve seen quite a few mentions of people having all sorts of difficulty getting this method to work on Android, so I’m a bit hesitant about heading down this path.

I’m thinking either option 1 or option 2 will be the way to go, so I will have to start looking into those options a bit more deeply.

In the meantime I might have a play around with the GUI side of things for a day, should be able to make a contribution or two in that aspect of the project.

Projects and Progress

How good it feels to have seen some advancement. We have a new project, that is a different project, and while we lost some time to working on the other project idea we now have some idea as to how we will complete the project. At least I do.

It’s good to be writing some code being able to compile it and see how it will fit into the project. We will probably have to work hard to be ready to demostrate something, but I think we’re on track.

Man blogging is lame.