Revised project vision & release plans

I have identified 3 steps to the realization of the myLock vision in the first weeks of research and initial alpha programming, therefore I am revising our overall design vision & release plans.

• The existing keyguard is an obstruction to end user convenience on the Droid since the device has no face buttons; since the only way to even awaken it is the power button on top (impossible to pocket-press accidentally vs the volume or camera keys could be) we will begin this project by simply bypassing the lockscreen automatically.
• The existing keyguard is not 100% obstruction. It does give us some examples of useful ideas that we want to retain. On the first screen the user sees on wakeup, it is a nice option to have clock display and some shortcuts. We will create a utility widget of sorts to converge the idea of the clock display, battery %, some power controls such as a brightness level button and optional switches for other power-consuming componenets, and of course the silent mode/vibrate toggle similar to the one on the default lockscreen.
• Finally, it would be useful to see a timeline of waiting events that have occurred while the device has slept in the wakeup or regular homescreen. The creation of this will be most complicated, as it seems it will require programming mini clients for email, twitter, SMS handling, and phone-event handling. I am not sure we have any way to talk to the existing notification panel or pull information from the default email client at all.

To define the boundaries of these goals then in release components:

• myLock: basic service which skips the lockscreen when the device is awakened, and gives the user customization of how they want to wake the device. This app is the first to be developed as it accomplishes the biggest part of our total vision.
• Untitled utility widget: a clock/utility interface that provides battery %, brightness & sound/vibrate shortcuts. essentially a converged tool to display a large digital-style clock that also gives access to most useful power controls and status indicators. Fills the gap left by the immediate skipping of the default lockscreen.
• WakeHome application: Replace the lockscreen with a home-like environment incorporating the myLock widget components, also allowing other widgets & shortcuts. The app will model itself after the default home app, minus the All Apps drawer at the bottom. Essentially a home on top of your home that comes up anytime you wake up the device. The advantage of this component is the nice flexibility of a new screen to house most important widgets or functions user would like to see immediately on waking the device, without compromising or detracting from how they would use the normal home screens. This is a separate component so that the user has the choice if they prefer to have the device wakeup to whatever they were last doing and place our widgets on their regular home screen.
• Event Timeline widget: provides a timeline for email, twitter, sms, and call events.

Suggested apps while ours is under construction

This week I came across several additional apps which offer some similar features and shared visions. Thought I'd finish out the week with a quick recap of what they are and how they can be used.

dxtop by accesslane - homescreen replacement which offers the option to disable the keyguard. The cool thing about it is a shortcut dock, multiple app drawers, and 5 home screens (A center screen and one for each swipe direction up down left right).

ScreenModeWidget by sam chiu - A very simple program that allows you to flip between default keyguarding, keyguard always skipped (meaning that any button will wake it up and you will not have to use the slide unlock screen, disadvantage is accidental vol/cam key while it is in pocket), and a never-sleep mode in which it keeps the screen awake till you exit the mode

Executive Assistant by Appventive - Another homescreen-like design, with the same specific goal of providing shortcuts and notification previews. They also give you the option to replace the keyguard, skip the keyguard to their interface (called welcome mode, this is most similar to how myLock is being organized), or just see their interface as a home screen replacement and keep the standard keyguard around.

Keyguard disabler by Mike DG - all it does is turn off keyguard. Works the same as screenmode. so if you want vol/cam to be able to wake up your device, get this and don't get myLock.

ShakeIt by androood - Very similar goal to the unlock modding part of myLock. Current builds of this have allowed shake to wakeup, shake to unlock, and a tool that gets speakerphone up by placing the phone in a certain orientation. I'm in contact with this dev to see if we can both improve our code for unlock/wake modification.

myLock is taking a similar approach to some of these features but is striving to be the most configurable and flexible for the different ways our users out there may want to unlock or access the previewer and shortCutter functions. An unlock customizer for the people.

My example home screen layouts

Icons come out of the android. You touch it, drag to the icon you want to launch, and release. Instead of being a lockscreen you now have a functional and minimalistic shortcut interface that responsively reacts when you need it, and otherwise remains hidden & compact so you can instead see the clock and waiting notifications that are more relevant when you're just viewing the screen to see what's happening or what time it is.

This is how I'm using the alpha.

This second image shows how the notification preview widget could work. You choose what types of messages and how much you would want to appear there, with an option to long-press an item to pop open a larger preview of the content (for example with email so you could preview the body). It is scrollable, also.

Alpha 1 implementing KGSkip is now up for download

Just now I coded in a receiver to start up the KGSkip service after system startup, and a settings screen you can use to start it up after initial download to fire it up without having to reboot your device. That's all the settings screen has for now since all this release does is demonstrate our KeyGuard Skip service! I removed the RemoteClient thingie that came with the tutorial I started from.

Major thanks to Adam K of SMSPopup for his ManageKeyguard code, and Sai Geetha whose remote service tutorial really jump-started my first alpha assembly. Please donate to them if you can!

Right now I've found the simple functionality incredibly useful for how I use my device. I can hit the button once and I'm greeted immediately by my last app screen, so I've been able to leave my gtalk running and accomplish my basic inspiration behind this app - be able to see my waiting google talk events in one button press wakeup while I am busy running around at work.

I have my home screen set with just my frequently used apps at the bottom - twidroid, gtalk, gv, email, dolphin, and facebook- and a digital clock widget kind of sitting center screen. shortCutter homescreen, notif_preview widget, and all the rest of the features I want to implement truly are just extra flair that enhances the Keyguard-free operating environment with customizability and control.

Go get it, and please if you discover a bug with how this interacts with other things (such as the phone, which I haven't deliberately tested a lot, so use with care if you are a big phone user with your device) leave me a comment, and any other feedback or suggestions you may have are welcome

http://code.google.com/p/mylockforandroid/downloads/list

The first building block of the myLock vision: free opensource keyguard skip

I coded this Sunday night, about 4 hours of bug-hell. Haha.

I still have to clean it up a little bit and figure out how to make the service just launch without having to press a button in the Activity.

I have posted the code up within the wiki over on the google code page.

It really is great, it respects the same relock conventions as one would be used to because all it really does is allow the phone to simply unlock when you press power, rather than forcing you to deal with the obstructive slider. The keyguard is actually there keeping other buttons from going off, it just gets skipped when you press power! So if you do nothing (view only) after that, it goes off after 5 seconds. If you interact then you revert to your timeout settings.

I love this as I can now have one touch preview of my GTALK most recent chat thread. In addition two touch notification panel.

I hope to push this out for download very soon, and work will begin on the official first build of the notificationpreview widget and shortcutter-centric home screen!

may also have to do a custom clock widget too. we'll see.

Why play by the official rules of the default keyguard?

A new possible direction for the design of the program occurred to me today. I was reading Mike dg's blog and in search of reference to the keyguard disabler source code, and the idea of the program really resonated with me.

With a capactive screen, the keyguard becomes somewhat useless. You have a nearly non-existent chance of dialing or activating ANYTHING on that phone with it in a pocket, so it just kind of gets in the way of normal phone usage. The root need being pursued by the simple disablement of the keyguard is the same as the desire to place useful things onto the lockscreen. The first thing you want to see when you wake the phone would obviously be either the last thing you were doing or a helpful shortcut and info preview area. This concept is synonymous with the idea of a great HOME screen, just enhanced with no obstructive keyguard in your way all the time.

The current default in 2.0 is part uber-useful (sound toggle) and part what's-the-point (keyguard). Once we kill the idea of the obstructive lockscreen (including security lock), we're left with how is the best way to put the user in control of good power management about waking the screen and having it resleep smartly, and how can we place really useful stuff on the first screen the user would see- a hub for the most important shortcuts and stuff happening on the phone's communcation. THIS is the real design goal of myLock.

So my thought was to implement this baby as either a homescreen replacement, or even as an app which simply makes the applicable tools available as widgets. So MyLock is really the combo of Lockbuddy and backlightwiz, which would allow all the fine tuning of different methods of waking the screen up and settings for how it would re-sleep. NotificationPreview, which is of course our customizable timeline, and then at that point shortcutter is kind of obsolete except as a nice UI for hiding your useful shortcuts (a la the sound toggle) away cleanly in your primary homescreen that outdoes the one-size-fits-all apps drawer-- I would retool it to basically utilize the concept from the illustration I posted where the shortcuts would be hidden and you'd just grab the android GO guy to have them appear.

Now that I've studied a little bit more of the basic different functionalities you're able to achieve in the android development and seen some of the craziness of the keyguard's default source, I feel like this is definitely going to be the way to go. I don't think we need to play by the rules of the default keyguard to accomplish our vision.

I may still go on to develop the opensource keyguard mod which could be utilized by devs who want to push a custom reminder up to the default-style keyguard (I have been in contacted with Adam K of Sms Popup), but I definitely want to take myLock in this direction developmentally first.

Roadmap for first alpha and the path to beta

To build the alpha we need to grab all the code that defines and invokes the current keyguard. Once I have all of this, and understand how each part works, I can take control of the keyguard for our purposes.

How I will take over (since we are not going to technically modify what's already there, which has been the only solution in the past thus it was done in cyanogen and the like for rooted devices), is to simply duplicate all the behavior that decides when to show the keyguard. My code will immediately hide the official keyguard again anytime it would be shown, then immediately invoke our clone instead! I imagine this has to be how flyscreen and Lock 2.0 have done it. Our clone will simply be an exact copy of the existing keyguard for the alpha.

This same code which takes control can also execute any lockbuddy functionality which introduces different ways to lock and unlock.

To reach beta, I will not be satisfied with it until I have the notification preview working for GTalk messages, which is the original inspiration for this idea. In essence the timeline will be functional in displaying any notification in order as they currently appear in the notification bar, just on the keyguard, and scrollable. I haven't noticed whether by default SMS displays message content, but I know that Gtalk does and the longer term goal for this tool is to display content from any message.

The 2nd beta release will have Shortcutter basic, which is the one in the illustration that lives at the bottom of the keyguard.

From there I will code the rest of lockbuddy and backlightwiz and think about going full release with the full messaging previewing.

Behold! First illustration of some of the functions planned for myLock!

Project Underway

Research and design thought is in progress for alpha version of the app. Please comment with any ideas or feedback. We are looking for programmers to collaborate with to get familiar with the platform faster, or at least some advice on source code resources to learn from.

check out the project site at code.google.com/p/mylockforandroid

Updates for this week: project page launched, initial wiki documents created for organization of thought behind the project. checked out apps that do new lockscreens- flyscreen, lock 2.0, lockbot. SMS notification/preview popups - sms popup, handcent sms. Backlight and lock apps- Backlight!, B&B backlight widget, ShakeIt, ShakeAwake

Checking these out has proven that everything we want to do with the app is possible, just hasn't been done all in one cohesive interface before.