Secure Flutter object storage/sharing with the atPlatform

Do you wish to store and share objects on Flutter without worrying about databases, infrastructure and other annoyances? What would these objects look like and how would you make them? The atPlatform already has you covered! Let’s take a deep dive into the AtKey object class and its attributes.

The AtKey object is stored on an atSign’s personal secondary server (a separate article written on secondary servers), so dealing with databases is not a worry on the atPlatform. There are a few distinct attributes that exist within an AtKey.

String? Key;

The key is the title or name of the AtKey object itself, may this be a recipe name (like mom’s secret recipe from at_cookbook), or maybe even the name of a weather update (like, cloudy or sunny).

String? sharedWith;

The sharedWith attribute is as easy to understand as it is to read! This is simply the atSign in which we wish to share this AtKey object with, or who the AtKey object has already been shared with!

String? sharedBy;

Similar to sharedWith, sharedBy is just who the creator or original sender of the AtKey object is.

String? Namespace;

The namespace is the name of the app where the AtKey object was created. This is why passing the regular expression to retrieve AtKey objects from specific applications is a possibility.

Metadata? Metadata;

Metadata, which is commonly known as the data about the data, will be described in its own video series as there is much to it!

Taking a look at one of the atPlatform’s demo application, we can see the AtKey object in action. The at_cookbook app allows a testable or production level atSign to create a recipe with a name, description, list of ingredients, and a picture. After doing this, the atSign is capable of sharing this entire recipe with another testable atSign. A dishWidget class is created which encapsulates an individual recipe with each instance. Its parameters are defined below:

class DishWidget extends StatelessWiatdget {
 final String title;
 final String ingredients;
 final String description;
 final String imageURL;
 final String prevScreen;

 DishWidget({
   @required this.title,
   @required this.ingredients,
   @required this.description,
   @required this.imageURL,
   @required this.prevScreen,
});
...

After we pull dishWidgets that exist in a secondary server, we display them on the home screen, where the list of recipes are located.

Now that you have the recipe itself, you’re able to pass this through the notify verb. When an atSign wishes to share a recipe, the _share function will be called. This function is structured as so:

_share(BuildContext context, String sharedWith) async {
 if (sharedWith != null) {
   AtKey lookup = AtKey()
     ..key = widget.dishWidget.title
     ..sharedWith = atSign;

   String value = await _serverDemoService.get(lookup);

   var metadata = Metadata()..ttr = -1;
   AtKey atKey = AtKey()
     ..key = widget.dishWidget.title
     ..metadata = metadata
     ..sharedBy = atSign
     ..sharedWith = _otherAtSign;

   var operation = OperationEnum.update;
   await _serverDemoService.notify(atKey, value, operation);
   Navigator.pop(context);
 }
}

Here, we’re initializing a variable called lookup as an AtKey object (lookup will be our recipe). You’ll notice that we’re defining a couple of the attributes of the AtKey object (mainly the name of the recipe and what atSign is this recipe being shared with).

We would like to “get” the values of our recipe, so we use the get verb from the serverDemoService file of the application. ttr (Time To Refresh), a metadata attribute, is called with a value of -1, which means that we’re confident that the values of our recipe won’t change. Once the recipe has been cached on the secondary server that has received the recipe, it will not need to worry about updating its values at any point.

After passing all of the necessary values such as the metadata, the appropriate atSigns, and the type of notification we’d like to send, we simply pass the values through the notify verb!