Over the weekend I got bored with my homescreen. I tried several widgets like BattStatt, Tajm, dClock, and TypoClock, but they all took up at least 2 rows of my homescreen, or I didn’t need the information. I loved dClock’s week display since the actual day isn’t obviously visible on Android anywhere but the lock screen. So I went ahead and made my own simple week widget over the weekend.
Obviously, the week widget needs to display the correct day to the user, which can vary depending on time zone. It should also know when midnight/the start of the new day is, so that it may change. I’ll share with you how to get the current time relevant to the user.
/**
* The private getDay method gets the current time zone and then returns
* the integer day of the week for this time zone.
*
* @return The day of the week (see Calendar.SUNDAY)
*/privateint getDay(){TimeZone t =TimeZone.getDefault();//gets the phone's curr timezone// create a our current time zoneSimpleTimeZone pdt =newSimpleTimeZone(t.getRawOffset(), t.getID());// set up rules for daylight savings time for 2010, US
pdt.setStartRule(Calendar.MARCH, 14, 2*60*60*1000);
pdt.setEndRule(Calendar.NOVEMBER, 7, 2*60*60*1000);// create a GregorianCalendar with the Pacific Daylight time zone// and the current date and time
calendar =newGregorianCalendar(pdt);Date trialTime =newDate();
calendar.setTime(trialTime);return calendar.get(Calendar.DAY_OF_WEEK);}
This method returns the current day of the week depending on the user’s timezone. The Daylight Savings is adjusted to this year’s US date’s, but you could easily add clauses to change it for other countries.
Now that you have the day, you can easily calculate where midnight will be (either by raw calculation or just create a new calendar and bump it forward to the desired date/time). I used AlarmManager to set a repeating alarm every day.
OneSeven is available in free and pro versions. Please click here to view the features of each.
Today, I’m launching my very first app under the Cryclops name. It’s called RingPack, and is currently available on the Android market in beta testing.
The idea started with a very simple desire. I get a lot of texts/notifications, and usually whatever ringtone I choose for my text ringtone (the Default Notification Ringtone in Android), I grow to hate after a while. It starts with loving the new tone, and being impressed with it for a few weeks, but then — just like a hit song on the radio — the repetition finally gets to me and I can’t stand it anymore.
RingPack started as a solution to this annoyance. I thought it would be kind of fun to not know what sound your phone was going to make next. Obviously, I want my actual ringtone (the one people get when they call me), to remain the same, otherwise I wouldn’t know what was ringing. But the text notification had some room to wiggle. So I came up with 3 main ideas I wanted to accomplish:
The first idea was to have the app shuffle around different, yet similar sounds. For instance, it would shuffle your tone between all known guitar chords in the key G. This way, you’d still be expecting the correct pitch, but you wouldn’t know the exact mood of whatever chord was coming.
Then I thought about theming. I loved Ocarina of Time as a kid, and wouldn’t it be cool to have a themed set of notification tones, all from the same game. That way, instead of just recognizing it by key, I would recognize it by association.
Lastly, I remembered my girlfriend, who always has the same exact song snippet as her text tone. “Still D.R.E.” That gets stuck in your head all day. Wouldn’t it be cool if your phone could progress through the song as you get texts?
So I thought I’d pack together ringtones in “packs” and make an app to manage them.
Long story short, after a month of development I’m proud to release the beta version of RingPack. I think you’ll like the UI, especially the implementation of custom QuickActions based on this tutorial. The app is based around a Service, to swap out tones in the background, and BroadcastReceivers, to tell the Service when it needs to make a change.
I ran into some limitations on my “perfect” idea of an implementation simply due to constraints in the Android framework. For instance, the only notification I can listen for is incoming SMS’s. Things like incoming Google Talk and Voice messages simply don’t seem to be a thing that I can detect. To compensate for this, I’ve given the user the option of listening for time ticks instead. You can have your tone rotate on either 1 minute or 5 minute intervals. In the future, I’ll probably give the user more options (perhaps once daily, weekly, after every phone call).
Features include:
Intuitive UI
(2×1) Widget
Shuffle, Lock, and Rotation preferences
Easy on the battery background service
Extend-able packs! (I’ll post more on how you can make your own packs soon)
I’m allowing Android 1.6 and up to install it, although users who are below Android 2.0 might experience some issues with the background service. Android 1.6 has some issues with restarting the service. I’ve done my best to try to fix those issues for now, but as I’m testing on 2.2, I can’t confirm for sure.
Known bugs:
The 1.6 thing
Playing mp3 ringtones very quickly (using the widget) will result in the mp3 decoder becoming overloaded and Android will panic and reset the Default Notification Ringtone to it’s most basic one. If this happens to you, simply open RingPack, select the “None” pack, then your desired pack and it will return to normal. I’m working on this. It seems ogg files may be a better choice.
After a restart, RingPack can take up to 1 minute to restate itself.
Sometime the interface is slow to respond. I’ve not been so good about breaking into Threads. This is my first priority to fix.
If the app Force Closes on you (which I’ve done my best to stop. In fact in the last week of testing, I haven’t hit any), it has the potential to leave a orphan entry in your MediaStore library. It’s not harmful, but if you’d like to clean it up, I recommended using the ever popular ringdroid. Just open it, click Menu>Show All Audio>Search for “ringpack”. If there’s an entry there, longpress it to delete it and you’re all cleaned up. There is a special case where the Service manages to delete the file, but misses the MediaStore library entry. Ringdroid will tell you that it couldn’t delete the file in this case, but it lies. The entry will have been removed from your library. I’ll definitely be implementing my own fix for this type of thing soon, but for now this works.
Lastly, screenshots can be found on the official RingPack page. Look there in the future for more goodies.
This semester at Virginia Tech, a friend and I lucked out with the opportunity to join up with a professor doing research in how to use smartphone features to save energy. We’re using things like the light sensor, the accelerometer, and the GPS to save energy in neat ways. However, the first app to come out uses none of these. Think of it as an advanced Hello World.
The idea behind greenHome is to give the user energy saving tips depending on their location in the house. It starts with a homescreen that lets the user pick what room they’d like tips about, then brings up a list of tips. We let the user navigate through these in some cool ways.
click to enlarge
The user can navigate through tips in this activity by either touching the left and right arrows at the top, or flicking left or right, as long as the flick is in the content. We used a custom ScrollView nested inside of a custom ViewFlipper to accomplish this with nice animations. I’ll post a tutorial on how to use a ViewFlipper soon.
What’s cool is that we share touch events between the ViewFlipper and the Scrollview, which is a bit tricker than you’d think.
//flipper is my custom ViewFlipper
flipper.setOnTouchListener(new MyOnTouchListener());publicclass MyOnTouchListener implements OnTouchListener {
@Override
publicboolean onTouch(View view, MotionEvent e){//give the scroller it's data//sc1 is the first child view of flipperif(flipper.getCurrentView().getId()== R.id.sc1)
scr1.onTouchEvent(e);//sc2 is the second child viewelseif(flipper.getCurrentView().getId()== R.id.sc2)
scr2.onTouchEvent(e);//reset on releaseif(e.getAction()== MotionEvent.ACTION_UP)
firstTouch =true;//check for a flick...returntrue;}}
The above code has some weird aspects. Stepping through it, we
Set the ViewFlipper’s OnTouchListener to MyOnTouchListener.
In the onTouch() method, we begin by handing down the touch data given to us (since we’re the parent in the layout) to one of our visible children (sc1 or sc2) by calling the child’s onTouchEvent.
Take care of flipping (I’ve taken that specific code out for simplicity).
Return true.
The un-important looking return true is actually very important. It turns out that if a view’s onTouch() method returns true, that means that this event has found it’s home, and it does not need to continue to other view’s. Logically, I would think that I’d want to return false here, since I’d love not to have to give out the event to my children myself, it would seem that Android would do that for me. However, I tried that and it didn’t work. Perhaps the event didn’t get handed to my ViewFlipper before it’s children.
For mine to work correctly, my ViewFlipper’s onTouch() had to give the event to a child, then return true. Also, my children’s onTouch() had to return false.
