It's an app that takes one photo every minute. Or every 5 seconds, or 10 minutes, or whatever. Wow! Imagine the possibilities!
(EDIT: it's unpublished from the market now because it crashed a lot.)
And it was a surprising pain! Some tips that might spare you some pain:
- don't try to use the camera without a preview. It might work, but I feel like some of the developers might have been assuming a preview. (all example usages of the camera, in docs and ApiDemos include a preview.) At any rate, using a preview surface gives you a couple of callbacks that make it easy to manage the camera resources.
- you might get cryptic crashes or ANR's. I don't feel confident that One Photo Every Minute is 100% crash free, even on the Nexus One I was testing it on. This is awful.
Some general thoughts:
- At work, on servers, we use Guice and dependency-inject everything. I tried to do the same here, and it was way overkill. You can, and should, easily bang out a couple thousand lines of code without doing any DI. (this means most of your code won't be unit-testable. I'm okay with that. No, this doesn't scale well.) Maybe I'll get into specific issues later.
- Model-view-controller is a nice pattern. This might be the app where I most specifically understood how it works, because I created classes called Model and Controller, and I designated the MainActivity class (plus the xml layout) as the view. Totally great idea.
- Learn one or two things at once. In this app, I tried to learn three (MVC, manual dependency injection, and Android camera apps). That will just frustrate you.
- Launch as soon as possible. Especially if you're fed up with the project. After you launch a functional product, if it's just a hobby (and if it's free), you can stop working on it at any time. Before you launch, if you give up, you've just wasted a lot of work. You can always add features later.
- It's amazing the difference between a free hobby app and a paid or corporate app. If Google or whoever launches a thing with a minor flaw, people jump all over it, sometimes nastily. (I know; I've worked on Chrome.) But when you release a free Android app, even if it crashes all the time, people are very friendly, even offering help and support! The feeling I get is "I know you're trying your best. I appreciate it." It's wonderful.
(EDIT: it's unpublished from the market now because it crashed a lot.)
And it was a surprising pain! Some tips that might spare you some pain:
- don't try to use the camera without a preview. It might work, but I feel like some of the developers might have been assuming a preview. (all example usages of the camera, in docs and ApiDemos include a preview.) At any rate, using a preview surface gives you a couple of callbacks that make it easy to manage the camera resources.
- you might get cryptic crashes or ANR's. I don't feel confident that One Photo Every Minute is 100% crash free, even on the Nexus One I was testing it on. This is awful.
Some general thoughts:
- At work, on servers, we use Guice and dependency-inject everything. I tried to do the same here, and it was way overkill. You can, and should, easily bang out a couple thousand lines of code without doing any DI. (this means most of your code won't be unit-testable. I'm okay with that. No, this doesn't scale well.) Maybe I'll get into specific issues later.
- Model-view-controller is a nice pattern. This might be the app where I most specifically understood how it works, because I created classes called Model and Controller, and I designated the MainActivity class (plus the xml layout) as the view. Totally great idea.
- Learn one or two things at once. In this app, I tried to learn three (MVC, manual dependency injection, and Android camera apps). That will just frustrate you.
- Launch as soon as possible. Especially if you're fed up with the project. After you launch a functional product, if it's just a hobby (and if it's free), you can stop working on it at any time. Before you launch, if you give up, you've just wasted a lot of work. You can always add features later.
- It's amazing the difference between a free hobby app and a paid or corporate app. If Google or whoever launches a thing with a minor flaw, people jump all over it, sometimes nastily. (I know; I've worked on Chrome.) But when you release a free Android app, even if it crashes all the time, people are very friendly, even offering help and support! The feeling I get is "I know you're trying your best. I appreciate it." It's wonderful.
I've actually thought of using Spring as a DI framework for android, but after thinking about it, it doesn't make sense to include all the overhead when android apps are supposed to be in self contained chunks (activities) anyways.
ReplyDeleteIs there a reason you consider the Activity your view and not your controller? I would think a View class (or xml-layout) would be considered the view.
Right, I mean, the XML layout is the view, but I figured, there's two Viewy things that you need to do in java:
ReplyDelete- findViewById() all your views that you defined in the xml, so you can use them in java
- an update() method or something, so all your changes to the UI get updated at the same time.
I put them in the Activity, because findViewById is implemented in Activity. It's conceptually ugly, because then you have class with an "and" in its description ("it's the activity and the view") but it also avoids having yet another class (I had 6 classes for about 400 lines of code. Kinda overkill.)
Of course, I'm just making this up as I go. If you have any better suggestions I'd like to know them.
Hello Dan
ReplyDeleteYour 'one photo every minute' app seems to have disappeared from Android market place. Is it still available?
I'm a clinical psychologist working in a stroke rehabilitation service in the UK. I have been looking at using memory cameras to promote memory rehabilitation for a couple of months. The only one on the market at the moment is the Microsoft sponsored SensCam (limited functionality; £600 each and totally out of the price range for the UK NHS). Not just the price though; most people just would not tolerate wearing it. However, many people have mobiles and we might be able to combine automated photo app with Goggle calenders to provide a reasonably cheap and user acceptable option.
Any assistance you are able to provide would be gratefully received.
Best wishes
Jimmy
Hi Jimmy,
ReplyDeleteSorry, I've taken One Photo Every Minute down, as it was very buggy and I didn't have the time to support it.
Have you tried other android apps that do similar things? I'm thinking:
https://market.android.com/details?id=uk.co.neilandtheresa.NewVignette&feature=search_result
https://market.android.com/details?id=com.autocamera1&feature=search_result
https://market.android.com/details?id=com.tina.time_lapse&feature=search_result
https://market.android.com/details?id=com.rumblerat.android.rrTimeLapse&feature=search_result
I haven't used any of these but perhaps they'd do the job for you.
Thanks for your work! I hope you find something that works out. What's the form factor? I mean, how do you propose to have an Android phone take pictures every so often if they're not wearing it? (if you figure this thing out, shoot, I'd enjoy trying it.)
Dan
Hi Dan
ReplyDeleteMany thanks for your response and the accompanying links. I have had a look at them all and trailed them on my Samsung Galaxy Tab. Time lapse seems to do a really good job and appreciate you pointing me in the right direction.
Just to let you know, the basic procedure is that the person wears the android phone around their neck on a lanyard (camera facing out). Flat wide phones seem to stay relatively still and a photo gets taken every 5 minutes. Photos are downloaded at the end of the day (some researchers have done this remotely, others manually). Blurred or unclear photos are deleted leaving a visual record of the day which the person looks through with the support of a family member. If we were designing this from the ground up a Bluetooth camera worn like a lapel badge would take better quality images. However, even poor quality images seem to prompt some recollection and the ubiquitous nature of mobile phones makes them a viable tool. Using visual images seems to produce a level of recollection in episodic memory (memories formed via direct experience) that verbal prompting or recall can’t. The initial findings are that only a small percentage of photos are usable and even fewer prompt a memory. This may not sound like much but represents a huge step forward for some people in recollecting day to day experience. It also seems to produce a relational benefit; in that the process and material help structure conversation with family.
Really appreciate your assistance on this
Best wishes
Jimmy
Great, glad you've found something that works! Yeah, I imagine it's a lot easier to reconstruct memories using pictures (even just a couple pictures here and there) than with words. Easier to record, too.
ReplyDeleteGood luck with the rest of the work, and to all the patients and users of the app!