One of the smartest guys in the ASP.NET world, Nikhil Kothari, just wrote a short piece and is sharing code for a Facebook app framework. Sweet. Check it out here:
I've had my "Jesus phone" as some have called it for about two weeks, and so far I'm pretty impressed. I just put it in the charger after more than two days, with about two days stand by, eight hours of "use" (not sure, but I think that's iPod use, Internet, everything but phone calls), an hour and a half of talk time, and about 12 MB down. That got me to the 20% left warning. Frankly, that's better than I expected.
The only thing so far that I really miss among the many lists of things it "should" do is picture messaging. I really have to think it's something that just didn't make the release, but I guess we'll see.
Relative to our world of ASP.NET and Web applications, I've toyed around with some ideas, none all that impressive. I haven't used any of the new UI libraries popping up, but I'm impressed at how quickly they're maturing. The iPhone Digg beta is really neat. The iPhone Ta-Da List is cool too. None of these are complex, but that's kind of the point.
I read a recent interview with Jack White from The White Stripes talking about how the constraints of the band, just him and his ex-wife, force a certain creativity and at the same time consistency. This reminds me a lot of what's going on right now with the iPhone and people developing Web apps for it. While it can do full screen browsing of a real page, people are adopting the UI look, making things smaller because of the sometimes slow EDGE network and generally rethinking the way they do stuff. Reminds me of the dial-up days when we used to optimize our HTML and graphics sizes!
So how does ASP.NET work? It works really, really well in iPhone Safari. In fact, a problem we're having at work with the production version of the AJAX framework and desktop Safari 2.0.4 goes away on the phone. Go figure. Also surprising is that it works pretty quickly. One of my old ASP.NET apps loads quickly despite having a lot of early baggage like untamed view state.
Sometimes constraints aren't such a bad thing, because they force you to think about what's really important and vital to what you're doing, and what doesn't really add significant value. Who knew an expensive phone could do that?
I unfortunately have a 40 minute commute, which sucks given my tree-hugger ways. I feel that at this point in my life it's not practical to move since I'm not "settled" in a relationship and could end up moving again anyway.
I have a ten mile stretch on I-271, a "bypass" that starts well south of Cleveland and goes northeast toward Erie. I use the word "bypass" in quotes because frankly it touches most of the east side. Anyway, there is only one exit in between my start and end, SR 8. That interchange is under construction with a massive interchange project. The bridges over the Cuyahoga Valley National Park are also being replaced. Basically, it's mostly construction. Then add to the fact that I-480 also merges with it, and you suddenly have the most ridiculous section of highway in Northeast Ohio, and it's mostly rural.
Traffic this morning was backed up to the valley. Not good. The construction at 8 puts it down to one lane, with the other lane forcing you to exit on 8. I actually got out of the house early, but clearly I was going to be late. It's always a gamble continuing on past 8 because you never know what the traffic will be like.
Then I realized that my iPhone does now. I pulled up the map, turned on the traffic overlay, and sure enough, a big red line on the remainder of that freeway. I got off at 8, and likely saved half an hour in the car. Given the value of my time, at least to me, I think I paid for a small percentage of the phone. :) Sweet.
A couple of years ago, when I was less focused, finished with my book and completely unmotivated to develop anything useful for my own non-day job projects, I struggled trying to shoehorn my apps into the ASP.NET Membership and Profile API's. Probably because of my lack of experience, I became very frustrated at the point where the objects started to relate to the data.
It occurred to me fairly recently that these systems provide a level of abstraction that makes sense in terms of data storage, but you still have to do a fair amount of work in your providers to make sure you aren't pounding the data store. That means caching, of course, but you still might be creating objects in several places (handlers, the page, user controls, etc.), and each time you're going to the well, whether it be by way of the caching mechanism you create or going to the data store.
So why cache at all? Why not get the data once, early in the request cycle, and go back to it when you need it? Oddly enough, it was good old fashioned FormsAuth that made me think of this, where in ASP.NET v1.x we would look up the user and roles, probably in an HttpModule, and access that data from where ever.
Yes, you can do this today with a well-written Membership provider, but it's more complicated than it needs to be. Not only is the interface fairly large, but then you have to create the various objects during the page lifecycle which in turn call the various pieces of the provider. It just seems like a lot of work. It means that in every piece, you have to call something like Membership.GetUser(User.Identity.Name), invoking the provider methods.
What if you did something a little more simple. Heck, use the Membership API if you want to, but do it once. Create an HttpModule that goes something like this:
public class UserContext : IHttpModule
public void Init(HttpApplication application)
application.AuthenticateRequest += new EventHandler(application_AuthenticateRequest);
private void application_AuthenticateRequest(object sender, EventArgs e)
HttpContext context = HttpContext.Current;
MembershipUser user = Membership.GetUser(context.User.Identity.Name);
public static MembershipUser Current
public void Dispose()
Then all you need is to call UserContext.Current from your code and you've got access to all that your user object has to offer. I used Membership here, but you could roll your own too. In fact, you could make this an abstract class and leave the implementation of AuthenticateRequest to a derived class, specific to your app.
At first glance, this seems like a very small win, but how much do you use user objects around your page? Furthermore, how much plumbing have you written to implement caching? When you eliminate all of that, suddenly your code gets a lot more simple, and a lot easier to manage. If I had a half-dozen user controls on the page that all had to access my user, and maybe manipulate it, at least it only has to read once from the data store, and I'm free to not write a bunch of caching code for subsequent object creation.
One caveat here is that you do need to keep thread safety in mind. If you don't use asynchronous page or handler methods, you're OK, but keep that in mind.