It turns out that my thinking on that topic isn’t going to become anything in the Adobe documentation. So I’ve sort of just been sitting on my ideas with the idea that someday I’ll probably share them.

Which brings me to this post.

Aside: upcoming presentations on multi-screen development

This is really a side note to the main ideas here, but I thought I’d mention it since it’s the reason I actually stopped to write this. In one of my mind-wandering moments this morning, I realized that at the upcoming 360|Flex conference (San Jose, March 7-10) I’ll be involved in two presentations that are directly related to practical aspects of building multi-screen apps:

• As part of the pre-conference free training, Joel Hooks and I are doing a four-hour training on using the Robotlegs micro-architecture. (Joel is the main speaker, fortunately, because he’s one of the core Robotlegs developers and the main “evangelist.” I’ll be helping out, to try and help save his voice and maybe to help find typos. =)

  If you’re wondering what a Robotlegs session has to do with multi-screen apps…keep reading, it’s explained below.

• On Tuesday and Wednesday, Renaun Erickson and I are giving (two separate) presentations about building iPhone apps using Flash Platform tools. My session is more of an intro into the workflow, how it’s similar to other app building, and how it’s different. (Plenty of code to look at — don’t worry!) Renaun is going to get more into specifics of building a game, as well as some more intermediate/advanced topics like performance.

Funny that I never really made that connection until this morning. I guess subconsciously I knew this is a direction I want to move in, and that’s why I’ve been focusing my learning (and hence my presenting) on these topics =)

Background

While I was partially trying to keep my thinking abstract, from a practical perspective I centered my thoughts around developing using the Flash Platform. So conceptually, what I was thinking about was the idea of making a single “app” for multiple screens, which would mean that (in the technology of the next year or so) it could be potentially take several forms:

• a browser/computer app (Flash Player)
• a browser/mobile app (Flash Player)
• a desktop app (AIR)
• a mobile (iPhone) app (Publisher for iPhone, similar to AIR)
• a mobile app for other devices (AIR)
• a TV app or widget (Flash for the digital home)

(Obviously many of these are only out in public beta, some have only been vaguely publicly acknowledged, and others may or may not ever exist as actual Adobe products =)

One app, or many?

Back when I started thinking about this, there seemed to be two main camps. One group was a strong advocate for the “single source” idea: you would build one SWF or one AIR app and distribute that same app on any platforms (desktop/mobile/TV). Obviously a key element to that, especially for desktop/mobile apps rather than browser apps, would be having code that detects screen size and device capabilities and adapts the UI to the device.

The second group felt that it was more likely that developers who are creating an app for multiple screens would actually create multiple apps (from the perspective of the IDE). The apps would obviously share some code, visual assets, etc., but would be different enough that they’d be created separately and distributed as separate file types. (In the case of apps created for the iPhone, of necessity this has to be true, at least in terms of the publishing part.)

Since I try to be pragmatic about things unless I have a really good reason, I favored the second viewpoint. However, I acknowledge that in some circumstances the first approach might be used. As always, I think that developers are going to use a mix of approaches.

For example, suppose I’m building an app and I want to create a version for desktop computers, a version for the iPhone, and a version for other mobile devices. Personally I see this not just as an issue of “porting” the app from one platform to another. I think that each device has its strengths, and more importantly, each device is used for different purposes and in different contexts. If I’m building an app for a device, I should definitely be taking that notion of context into account as I’m designing the app. That pretty much rules out the possibility of using the exact same app (UI and everything) for both computers and mobile devices, unless I want it to run as a widget-type app on the desktop.

Also see: Adobe Flash Platform contextual applications developer center

Adaptable code to the rescue

On the other hand, that doesn’t mean that developers will always create completely separate projects. For example, suppose I’m creating an app for iPhone, and another for another mobile device. Or perhaps I’m using the Publisher for iPhone to create an iPhone version of my app and an iPad version. If my app is a game where I can more freely discard the conventions of the platforms, perhaps the only platform difference I need to consider is the difference in screen dimensions and pixel density. In that case, it’s quite possible that I can .

Even for a more line-of-business or productivity app, one of the key ideas in Slider, the future Flex mobile framework, is to (as much as possible) abstract away platform convention differences. For example, if iPhone usually puts the back button on the top, and another platform puts it on the bottom, and another platform puts it in a menu, and another platform has it assigned to a physical button on the device, then Slider might have a “back” event that you can hook into, and you can make your app perform the necessary “back” tasks regardless of platform.

Design patterns to the rescue

And, of course, in some situations you’ll almost surely need to create different versions of apps for different screens. For example, suppose you’re building a desktop Twitter client and a mobile Twitter client. Chances are good you’ll put some functionality into the desktop version that doesn’t go into the mobile one — such as previewing images, or maybe Facebook integration. On the other hand, adding a feature like automatic location tagging would make lots of sense in the mobile version, but not so much in the desktop one.

As I was thinking, many months ago, about the idea of efficiently creating different versions of the same app for different devices, a thought hit me like a ton of bricks. This is exactly the use case that the oft-mentioned “separation of concerns” is designed for:

Over several years, various “micro architectures” and “application frameworks” have emerged and waxed and waned in popularity. Many of these architectures are modeled around the “Model-View-Controller” design pattern (or its many variations).

One of the key benefits that these architectures claim is that it helps you keep the pieces of your application separate, without explicit links and dependencies between them. I’ve looked into and even tried out several of these over the years. One example that is frequently used to describe the notion of separation of concerns, which I always struggled with, goes something like this:

Suppose you’re creating an app, and you build the user interface and the other logic like server communication and data processing. If you use MVC/separation of concerns, then it’s really easy to just rip out your whole user interface layer and replace it with a new one.

They usually lost me with that one. As much as I tried, I couldn’t imagine a situation in which I’d want to build my app and then just rip out the UI and replace it with a different one note 1.

Until now.

Suddenly I had discovered, for myself at least, a real-world use case for the separation-of-concerns-so-you-can-swap-out-the-UI argument. If I’m building an app for the desktop and mobile, I’d like to be able to reuse my code where I can. At the same time, some functionality is only going to apply to one app or the other, so it’d be nice to be able to plug it in cleanly. Oh and by the way, the user interfaces are going to be different, so being able to swap those out is an absolute must.

I’d always liked micro-architectures in general, if only because I like knowing that I’m building my app using some pattern or structure that is based on developers’ real-world experience. It’s much nicer than trying to invent it myself and having to deal with all the pain points they’ve already gotten over. Now that I am imagining a world where I create multiple versions of the same app, with similar functionality but different user interfaces, suddenly micro-architecture patterns have become indispensable in my mind.

Conclusion

These are only just a few of my thoughts about the future world of multi-screen, contextual applications. Like Lee Brimelow, I believe that going forward building multi-screen, multi-context apps is going to be a much more common scenario. From my perspective as someone who thinks a lot about user experience design, and trying to optimize tools for the task and context, I think this is one of the most exciting aspects of the current technology revolution. I’ll definitely continue to share my thoughts and ideas in the future (hopefully more practical ones, too, not just abstract ones like this =)

Notes

Note 1: Just to be clear, I’m not trying to sound negative about MVC or micro-architectures/frameworks. Most of them provide many benefits, many of which are also related to the idea of separation of concerns, such as making code easier to test, making code cleaner, reducing boilerplate code, providing structure so that teams or developers who inherit a project can get going more quickly, etc. Swapping out the view layer is just one little benefit they mention. (back)

For lack of a better name, I call it my “AIR SQLite utility library”

The code currently contains one major piece of functionality (well, two different variations on one bit of functionality), which is a SQL “query runner” library. This is a wrapper for the AIR SQL classes that allows you to run a SQL statement by just passing a few bits of information:

• The text of the SQL statement itself
• An object containing properties with the values for any statement parameters in the SQL
• A Function to call when the operation completes
• A failure Function
• (optionally) a class to use as the data type for the data returned from a SELECT statement

The library does all the work of creating SQLStatement objects and caching prepared queries, as well as pooling SQLConnection instances so you can execute multiple statements simultaneously. It also has a variation that allows you to specify a “batch” of statements to execute, and they are executed in order in a transaction.

I’ve also got an additional utility to add to the library. It’s a “database copy” utility that allows you to create a “deep copy” of a database — all it’s tables, views, etc. — with or without data. The key reason why this is useful is that you can use it to create an encrypted database from an unencrypted database (and vice-versa). It’s written and tested, but I decided to modify the structure slightly before releasing it, so it’s not checked in yet.

I’ve put the details about how it works and why it’s designed that way in the project page. In case you’ve ever wondered how I design apps, I think the examples and this library give some insight into how I actually do my database-driven AIR app development. At least, how I structure the data-access part of my apps.

On (another) personal note, this project is also my first project that I’ve posted to my Github repository (as opposed to projects I’ve forked). It was actually posted-but-not-advertised on Google code for a month or so, but I decided to move to Github because the collaboration and checkin-without-network-connection features are so awesome.

Adobe AIR data privacy and security slides, notes, and links (1 MB .zip)

As a side note for those who actually attended the presentation, in retrospect I think I over-emphasized the security concerns and didn’t emphasize enough that there are plenty of use cases for which AIR is definitely secure — especially in the case where you need to keep the user’s private data secure. Hopefully the notes that accompany the slides help to clarify this somewhat.

I also used and referred to a number of resources in my presentation, which are listed below. The download .zip with the slides also includes an html page with all these links.

Introduction

• "Maintaining security with Adobe AIR" by Ethan Malasky and Peleus Uhley (Adobe MAX 2008)

Background

• "AIR security" (Adobe AIR documentation)
• "Why Adobe AIR Doesn’t (Yet) Include the Feature You Most Want" by Oliver Goldman
• "Understanding the Flash Player Security Model" by Deneb Meketa (Adobe MAX 2008)
• "Considerations for using encryption with a database" (Adobe AIR documentation)
• "Using digital rights management" (Adobe AIR documentation)
• Operating system security (user and "admin" rights)
  • "What are Adminstrative Rights, Anyway?" by Oliver Goldman
  • "Does Installing an AIR Application Require Admin Rights?" by Oliver Goldman
• Source code visibility
  • Action Script Viewer (ASV)
  • "Ethical SWF Decompiling" by Lee Brimelow
  • Nitro-LM
• Encryption: ActionScript crypto libraries:
  • as3crypto
  • OpenSSL (partially) cross-compiled to ActionScript using Alchemy

AIR application installation

• Sign your app with a trusted cert
  • "Code Signing in Adobe AIR" by Oliver Goldman
  • "Digitally signing Adobe AIR applications" by Todd Prekaski
  • Promotion: get a free signing certificate (while supplies last) by submitting your app to the Adobe AIR marketplace
• Plan for updates
  • "Building AIR applications that can be easily updated" by David Deraedt
  • "Using the Adobe AIR update framework" Quick Start article by Jeff Swartz (Adobe AIR documentation)

Modular applications

• Sandbox bridge
  • "Scripting between content in different domains" (Adobe AIR documentation)
• XML signature validation
  • "Creating and validating XML signatures" by Joe Ward
  • "Using the XML signature validation classes" (Adobe AIR documentation)
  • "flash.security package" reference (Adobe AIR documentation)

Local shared objects

[No links]

Encrypted Local Store

• "Storing encrypted data" (Adobe AIR documentation)
• "EncryptedLocalStore class" reference (Adobe AIR documentation)

Local files

[No links]

Local SQL database (SQLite)

• SQL injection attack
  • "Using parameters in statements" (Adobe AIR documentation)
  • "SQLStatement.parameters property" reference (Adobe AIR documentation)
• Encrypted database
  • "Using encryption with SQL databases" (Adobe AIR documentation)
  • "Using the EncryptionKeyGenerator class to obtain a secure encryption key" (Adobe AIR documentation)
  • as3corelib project (includes the EncryptionKeyGenerator class and hashing algorithms

As David pointed out, the fact that I’m an Adobe employee and am participating in the project doesn’t mean it’s now an official Adobe product (for good or bad). I’m doing this 100% on my own time. And my role is still pretty small — David is certainly the lead, main, primary, controlling, etc. author. I just file bugs as I find them, add some comments about feature requests, and fix issues when I know how to.

In case you’re curious, the back story is really pretty straightforward. I started writing my own version of an AIR SQLite admin tool back before AIR beta 1, but never had time to take it beyond a “query runner” tool. Late in 2008 I discovered Lita, and once I started using it I realized that 1) it is implemented in a similar way to many of the ideas I had, and 2) It’s already got a big head start in features, so there’s not much point in me trying to “compete” or anything like that, especially for something that I wasn’t planning to make money from.

After using it for a while I discovered a few bugs, and decided to email David about them. (He and I had communicated a bit previously, about the encrypted database functionality added in Adobe AIR 1.5 and how to integrate it into Lita.) I think I probably mentioned in that message that I would be willing/interested to fix issues myself as I have time. Fortunately David was very kind and accepted my offer. So, as I said, now when I find issues I get to fix them myself, which is nice because I can fix them quickly, but also adds some responsibility since now the burden is on me to make those changes myself =)

As a side note, I really want to point out that David is a really great developer — something I appreciate greatly as we work in the same codebase. It is a big testament to his architectural and coding skills that I was able to dive right in and fix four bugs/feature requests in a very short time (literally a matter of minutes after first looking at the code). I’ve learned a lot just from seeing his code, and now I’m anxious to read his “Flex Architecture Fundamentals” series to learn more about the thinking behind the great code.

In spite of the bad timing, it’s a nice, thorough article that gives a good view of things that we can do to make our apps more secure, in addition to security updates that Adobe continues to make to Flash Player.

(via email from Jeff Swartz)

Here are the direct links:

• Grant Straker on Moving ZoomFlex from a homegrown framework to Cairngorm
• Ali Mills and Luke Bayes on Flex application frameworks (A great overview of the strengths and weaknesses of various frameworks like Cairngorm etc., from two really smart developers.)

Enjoy!

(via email from SilvaFUG)

If you’re interested in a summary of the talks, I’m afraid I didn’t do that. (But I highly recommend viewing the presentations:

• Grant Strake on moving ZoomFlex from a homegrown framework to Cairngorm
• Ali Mills and Luke Bayes comparing various Flex application frameworks

What I’ve written here is primarily just thoughts that I wanted to save for myself; things that maybe I don’t think about as often as I should, or things I want to remember about the audience of Flex and other Adobe developer products. Because I’m interested in the developer community, much of the focus is on points about the developer community that I sometimes need to remind myself of.

Grant Straker

The first speaker was Grant Straker, talking about his company’s choice to use a homegrown framework, and eventual decision to migrate it to Cairngorm instead. His company (Straker Interactive) has a RAD product (“ZoomFlex,” I believe it’s called) that bundles ColdFusion and Flex to create apps quickly — you use wizards to define data structures, and the product generates database structure, backend ColdFusion, and front-end Flex code for apps using that data. (The idea is that developers then take those Flex files and customize the front-end forms, style the app, etc.)

Here are some interesting thoughts/points I picked up:

• Originally they chose not to use Cairngorm for the underlying framework for their generated code. The reason: while there are some developers who build big, fancy, complex enterprise apps, there’s also a group of developers who “just want to know what they need to know to get their job done” — which often means build basic CRUD apps as quickly and easily as possible (e.g. web-enabling existing databases, spreadsheets, etc.). This latter group was/is more in their target audience.
• Code can be written in different ways — they try to generate code so that it’s clear and obvious what it does, and so that it can be easily extended by developers of varying levels of experience (key: don’t assume a high level of experience).
• In retrospect, he wishes they had just stuck with Cairngorm in the beginning. Now, 1.5 years later, there’s a large community, examples, documentation, etc. making it easier for a less-experienced developer to learn enough Cairngorm that they can understand it and use it.
• I was really amazed by how much code they are able to generate for developers. I’ve read some things about code generation tools, but I’ve never tried them out (due to the organizations I’ve worked for, and perhaps due to my personality as a developer who likes to have “control” of the code). However, I’ve definitely seen the down side of that, which is that I end up writing a lot of redundant or very similar code (especially for data access and manipulation). The “alternative” approach certainly has some attractions…
• Part of what they include is a library of pre-built UI components. The process of migrating these components to Cairngorm has been challenging at times. One of the principles of many frameworks including Cairngorm is that the user interface code is separate from the “model” (the underlying data). However, some components by nature lend themselves to having knowledge of their underlying data (e.g. their video player component) so figuring out how to structure those components is complicated.

Luke Bayes and Ali Mills - Evaluating application frameworks for Flex

Luke and Ali came into this presentation with no background in any of the major frameworks (other than the Flex framework). This is good because they didn’t have any biases, but it means they may have some non-best-practices too.

This was a great talk, but there was a lot of info in a short time so again, I’m not going to bother trying to write detailed notes. I highly recommend watching the recording.

However, once again in this presentation (in particular in the discussion afterwards) some of the same ideas came up. Luke in particular expressed a reluctance to have a prescriptive framework, because he doesn’t want to be “told how to code.” That opinion resonated with most of the audience there — but at the same time, everyone also acknowledged that the audience at a user’s group presentation isn’t really an accurate representation of the broad Flex developer community (especially the even broader community of developers who are considering Flex or who will be Flex developers in the future). If the Flex community is going to continue to grow, and be more accessible to new developers, it would be very helpful to have some prescriptive application frameworks that give people a predefined, standard architecture within which they can build their app (in the same way that Flex’s components provide user interface elements and layout elements that give developers a big head-start in building an app, compared to straight ActionScript or Flash).

What is the “next frontier” of Flex developers? Is it the “VB developer”1 (the “behind-the-firewall” corporate developer). If so, then to support that group of developers we’re going to need prescriptive frameworks that are easy to get into (“accessible” in Luke and Ali’s terms), that do as much work for you as they can, but that still don’t get in the way as an app grows in complexity.

At the same time, more advanced Flex developers may not want such a framework, and they certainly aren’t going to want to have to carry along the “baggage” (meaning both prescriptive architecture imposed on them, and literal baggage in download size) that would come along with such a framework if they’re not using it.

Personally, I think that’s an extremely important point for both Adobe and third-party framework developers to keep in mind going into the future.

“VB Developer” is my name for a developer who works in a medium-large corporation or organization, perhaps coding apps for a group within that organization, who doesn’t really want to learn everything there is to know about Flex (or their language of choice), or become a “guru,” but rather just wants to build their app and make it work nicely, but do so as quickly and painlessly as possible. Yes, the name “VB developer” is rather dated, since at this stage in history most such developers are doing web-based apps, probably using ASP.NET or J2EE in a large, standardized org or perhaps PHP or Ruby in a smaller or more independent group.

Keith Peters wrote a similar post on the same topic, which I also recommend.

(via Jesse Warden)

I definitely agree with his conclusion — one of the strengths of AIR is that you can use either, or both, of these approaches depending on the needs of your app.

As a side note, the AIR documentation also includes some introductory content on relational databases, SQL, and related concepts — although I intentionally kept it limited, since the topic of relational databases is so vast that many books have been written about the subject.

Tim also raises other concerns which aren’t so much issues to keep in mind when developing AIR apps as they are issues surrounding the documentation. I’ve attempted to respond to those concerns in a separate post.

Tim says:

unlike [Google] Gears, AIR makes no attempt to isolate databases based on the origin of the application. In AIR, a SQLite database may be anywhere in the file system, and it’s equally available to any AIR application - a big hole in the AIR sandbox.

I think Tim raises an important point (although I disagree a bit with his conclusion). Very soon after I started working with the local SQL database functionality in AIR I realized the same thing — since any AIR database can be read by any AIR application, it means that I can write a database application in AIR, and you can write an application that finds the file I create with my app, and reads its data.

But let’s take a moment to get a little perspective, after which we’ll consider what we can do about it.

It’s true that in AIR, a SQLite database may be anywhere in the file system, and in general it’s equally available to any AIR application. However, while this differs from Google Gears’ approach, there are some key reasons why this difference is allowed, and why it’s not considered a “big hole” security-wise.

First of all, there’s a significant difference between Google Gears and Adobe AIR. Google Gears is an extension to the standard capabilities of web browsers, but ultimately an application that uses Google Gears runs in a web browser and is therefore subject to all the security constraints of a browser-based application. This is similar to content that runs in the Flash Player browser plugin, or in a non-Gears-enabled HTML/JavaScript application — neither of which can freely access a user’s hard drive. Why is that? Well, it’s because all it takes for a user to access a Google Gears application is for the user to visit the url of that application in his or her web browser. That could be by clicking a link, or even by an automatic redirect that the user has limited control over.

On the other hand, an AIR application doesn’t require or use a browser. In order for a user to access an AIR application, he or she must first choose to install the application, including going through a security dialog that will describe whether the application was signed with a security certificate. In this way, an AIR application is comparable to any other desktop application, such as one written in C++. Since any C++ application could theoretically include the SQLite library, installing an AIR application is no different from installing any C++ application in the sense that, by doing so, a user opens himself up to possible abuses and security risks.

Likewise, any application that can read files from the file system (AIR or not) has the same potential for “stealing” sensitive information. If someone has written down his passwords in a Microsoft Word file, an installed application could search the hard drive for all Word files and read them all and send their contents to a malicious author. Even if your application uses a custom binary file format, there’s nothing that can be done to prevent someone else from reverse-engineering your file format and then writing an app that reads your files and extracts the data. Of course, it’s true that by using a SQLite-format database file, in return for the convenience and benefits it gives you, you’re saving Joe Evil the trouble of needing to reverse engineer your file format, and instead you’re handing your data over quite handily in a wonderful structured way.

On the other hand, all this openness actually has benefits. Since my app can read files written by another app, I can write two different apps that can understand each others’ data. If I make a certain kind of app, and later you make another app that does the same thing but does it better, you can read my file format and import my data into your app — meaning you can help users migrate from my crummy app to your awesome one.

Having said all that, I don’t want you to think that I’m simply washing my hands of the issue. I think it’s an extremely important one, and I’m very glad it came up.

Tell me how to fix it, already

All openness aside, if you’re storing sensitive data in your application, data that you don’t think other applications ought to be able to read, there are some things you can do to try to minimize the potential for damage. Note that since the problem isn’t exclusive to apps that use a local SQL database (although it is perhaps more apparent for those apps), the possible solutions aren’t exclusive to local SQL databases either.

Use user-specific directories

Every AIR application has a special folder in the operating system that can be used to store files related to the app. The folder, known as the “application storage directory,” is actually different for different logged-in users of the same application. In that way it’s a convenient way to separate files for different users of your application. It’s location is always available using the File.applicationStorageDirectory property. Similarly, you can access the directories representing the user’s desktop and his/her documents directory; again, these are folders that will be different per-user, but your app can use the same code to access them regardless of who is using the app.

Note that this only provides limited protection. Any AIR app or any other app can traverse the file system (assuming the logged-in user has permission to do so) and discover and read files in the application storage directory or other user-specific directories. So while this might protect files belonging to other user accounts (if the user running the malicious app isn’t an administrator), it won’t protect files belonging to the logged-in user.

Encrypt your data

The most reliable way to protect sensitive data from other applications is to encrypt it. This can be done in a couple of ways:

• Encrypt the database file itself. This approach could be somewhat involved. When a user opens the app you’d decrypt the database file and store the decrypted copy in a temporary location from which the app would actually access the db. Then, when your app shuts down (or at some other time) you’d encrypt the temporary file and save the encrypted version wherever you store that master version, and delete the temporary file. As a simpler but less secure variation, you could use a simpler form of encryption. For example, you could append some bytes (either random or meaningful) to the beginning of the database file (or end, or middle or any combination of the three). Before using the database file, you’d need to remove the extra bytes, of course, and actually access the unencrypted version of the file with your application.
• Encrypt sensitive data within the database. Rather than encrypting the entire database file, if your application stores some data that would be considered sensitive, you could simply encrypt the raw data before writing it to the database in your INSERT/UPDATE statement, then decrypt it after reading it with a SELECT statement.

Note that in both of these cases I’m talking about using a two-way encryption algorithm. Typically such algorithms require you to have some sort of secret — the encryption key — that is used by the application to encrypt and decrypt the data. Since an AIR app consists of HTML and JavaScript files (plain text) and/or SWF files (binary, but known to be de-compileable), you won’t want to store the encryption key for your application within the source code of your application. Rather, you’ll want to generate the key for each user, and store it separately from the application data. Christian Cantrell’s “Salsa” application demonstrates how to do this (it actually uses a user-selected passphrase as the encryption key, although the release notes say that future versions won’t require that) so that’s an example app to look at for an example of two-way encryption.

Not just reading

On a somewhat related note, another concern with other applications being able to access your app’s data has to do with the integrity of the data. Not only could another app read your application’s data, but it could just as easily change the data as well. Apart from two-way encrypting the entire database file, there isn’t really any way to protect against this. If you don’t want to encrypt the entire database file, one way you can at least verify the integrity of your data is by using a one-way encryption algorithm (also know as a hash). It works like this:

1. After closing your database, your app encrypts all or some of your database (either the bytes of the db file, or the db data) using a one-way encryption algorithm.
2. The next time your app opens your database (or before opening the db if you hashed the file itself) you run the same file (or portion of the file or data) through the encryption algorithm again.
3. If the source data (your db’s contents) hasn’t changed, the resulting hash value should be identical. If the contents of the database have changed, the resulting hash value will have changed — meaning the data has been tampered with by something other than your application.

You could even combine an integrity check with two-way encrypting the file. For example, you could create a hash of all or part of the database file, then append the result to the file. When you reopen the file, you would need to extract the hash, then you could compare it to the rest of the database as well as using the database file (minus the hash) for your application.

Finally, I should acknowledge that, while I’ve done some study of encryption and securing applications, by no means do I consider myself an expert on the topic. If anyone has other ideas, suggestions, and especially if you see some issues with the techniques I’ve recommended here, please share your experience!

The part that caught my eye the most was that the wrapper class doesn’t dispatch any events to notify the view when the operations have completed. How, I asked myself, does it notify the view when the updated data loads? After a few seconds I realized the answer — it’s the magic of Flex data binding. The DataAccess class exposes the SELECT results as a property (dbResult) that’s a Flex ArrayCollection, and it’s marked [Bindable]. A Flex control can bind to that property as a data provider, and whenever the DataAccess instance reloads its data and updates the ArrayCollection. Then the Flex framework takes over, and the view gets updated automatically. Pretty slick; and it definitely saves a lot of event-handling code. So I guess seeing this in action gave me further appreciation for the power of data binding.

It has a couple of minor issues that I’ve noted in the comments on that page (but mostly they should be fairly easy to fix, if Brandon or someone else decides to do so).

(via: Greg Hamer)

Brian is one of two (at least so far, maybe there are more) authors writing on the Adobe Kiwi Project blog. The Kiwi Project (as stated in the tagline of the site) is a project which is working on creating “Read/Write Web Components for Flex.” I’m not sure of the details of what that means, but parts of it can be seen in the open-source NoteTag note-taking application which Brian uses as his example in this and other articles, and which is available on the Adobe Labs site.

Darrick Brown, who also writes on the site, has put up a couple of nice articles on ActionScript 3 from a C/C++ perspective. I don’t know either of those languages, although I work a lot in C# so I understood all his examples just fine. In any case he’s got what I think are some nice examples and thoughts for someone coming from any modern language.