i3Factory World

Your Iphone, iPad & Android Application Factory

Browsing Posts tagged Editorial

i3Factory World  accompanies the Ministry of Labour through the i3Editorial Editorial System lands on the App Store.
An easy way to keep up to date on the world of work. Newsletter Cliclavoro is a monthly feature that collects the most important industry news, trends in the labor market, opportunities in Europe, interviews with personalities.

The newsletter is divided into 5 sections:

in opening
deepening
The interview
From Europe
From the Social Network

Keep up to date on market trends, with data and information enriched with links and multimedia content.
To follow in real-time news from the world of work CliComunica download the application.
Apple iPhone and iPad Version: https://itunes.apple.com/it/app/clicomunica/id582587332?mt=8

Android version: https://play.google.com/store/search?q=clicomunica&c=apps

This article was written to our CTO, Carlo Vigiani, for iCoder magazine

One of the great improvements in all iPad owners lifestyle is the possibility to bring everywhere any sort of magazine or book, thanks to the screen size and the device light weight which both facilitate reading and carrying. In particular reports demonstrated that in a printed publications decreasing market there is a huge increase in the number of subscriptions to the digital versions of the same product (the interested reader can read this report from MPA: http://www.magazine.org/association/press/mpa_press_releases/mag-mobile-reader-study.aspx)

Apple is following this trend with great interest, and this is quite clear if we take a look at the evolution of the iOS features that have been introduced since the release of the version dedicated to iPad, that is 3.2.
In the particular the milestones that have been reached are three, shared between three major releas es of the operating system:

•     iOS 3.2 was enriched by the CoreText framework, a technology dedicated to rendering text on display available since long time on Mac OSX and  never ported in the earlier versions of the iPhone OS.

•     iOS 4.x introduced the concept of auto-renewable subscriptions, as an addition to standard non consumable In App Purchases; this feature has been introduced after long discussions between Apple, that applies the 30% commission on every In App sale and forbids any other external cheaper store access within its devices, and the publishers looking for customer fidelity techniques.

•     finally iOS 5.0 added the Newsstand feature, which provides a central place to collect all magazine and newspaper apps and at the same time provide night-time content push to all subscribers, letting them to immediately read the latest issues of their publications and saving them for the extra time (sometimes long) required for the download.

What Apple didn’t provide instead is a common and unique developer platform dedicated to the creation of apps dedicated to the magazine consumption. This lead to a lot of initiatives dedicated to help publishers to enter in the iPad market with their own magazines. These initiatives were taken by major and well known companies, such Adobe with its Digital Publishing business, and a lot of many start-
ups, everyone with its own solution.

As I said, Apple doesn’t provide a unique solution, but developers have the availability of a set of frameworks and techniques, with different levels of complexity, that provide different way of representing the page on the screen.
There is not an optimal choice, as the final decision needs to take care of aspects that go beyond pure technical considerations.
In this article we will try to depict these solutions mainly from the app developer point of view, but will never forget to enumerate the pro and cons that can affect the publisher decision on which technology to adopt.

Page rendering overview
We assume that you, the developer, are in a certain point of your app development where the magazine has been purchased, downloaded and it’s ready to be read. Your document data at this point is safely stored in the device file system and it can be represented by a single pdf file, or a collection of html and css files or a directory containing assets of different formats, such as images, videos, html5 widgets, text files. You’re now facing the problem of taking one page (which can extend beyond the screen boundaries) and presenting it in the empty space of your UIView dedicated to the
page rendering.

In the next post I will present the following methodologies to achieve this result:

•     pdf document rendering
•     pre-rendered image display
•     free format CoreText rendering
•     web based approach

01/2012 – source: www.icodermag.com

 

Icona Newsstand Icon

The iOS5 revolution

A lot of water has flowed under the bridge since our first part of this tutorial. We’re sorry for the delay, but at the time of writing we were aware of the new featured introduced with iOS5 but we were still under NDA and not authorized to disclose anything about the SDK. Finally we’re now able to provide our example magazine app with the double iOS4/iOS5 compatibility.

 

I will not spend my time explaining all the Newsstand features, all in all we’re creating a magazine app here and the Newsstand implementation details go beyond our original purposes. I have written a two parts tutorial in my personal blog that you can read here and here, and that covers all Newsstand aspects and the required (by Apple reviewers) subscriptions. In short, Newsstand is both a new way to present magazines in the iPad and iPhones, where the original icon is replaced by a cover of the magazine or newspaper and is placed under a special group dedicated to collect all Newsstand icons installed by the user. For the developer it is also a framework, called Newsstand Kit, that introduces a new methodology to organize, download and install the app content.

The example app

The screenshot shows the final appearance of the app. A set of nine magazines with their nine fruity cover. You can download a magazine, see the progress bar change while the operation is in progress and finally read it. The other screenshot shows the appearance in the Newsstand. The typical icon has been replaced by a magazine-like representation inside the Newsstand group. The same, if run on an iPad with iOS4 installed will show the classical icon instead.



The full app code is available on GitHub. Don’t consider it as a production code, so please don’t try to reuse as it is with your clients unless you have tested it in all possible corner cases. Anyway it can be considered as a valid starting point for real apps. Essentially the principles behind the code architecture have been depicted in Part I of this tutorial; if you haven’t read it yet I recommend to jump to that article before entering in this one, at least to understand the key components of such an app. The driving aim is to keep the issues management (controller, don’t confuse it with “view controller”) separated as much as possible from the UI concerns. This means that in theory the whole code behind the Store Manager and Issue Models part can be reused even in a Mac OSX app, as they relationship with UI stuff is minimum.

I have setup this app using the basic single window Xcode template and then added the two main components in the application delegate startup method:

- (BOOL)application:(UIApplication *)application didFinishLaunchingWithOptions:(NSDictionary *)launchOptions
{
// here we create the “Store” instance
_store = [[Store alloc] init];
[_store startup];self.shelf = [[[ShelfViewController alloc] initWithNibName:nil bundle:nil] autorelease];
_shelf.store=_store;self.window = [[[UIWindow alloc] initWithFrame:[[UIScreen mainScreen] bounds]] autorelease];
self.window.rootViewController = _shelf;
[self.window makeKeyAndVisible];
return YES;
}

The two components are:

  • the Store class, which represents the Store Manager block in the app architecture; this Class is a subclass of NSObject and is not linked to the user interface.
  • the ShelfViewController represents the UI of the application. It is linked to the store using a specific property. Note that the controller will not access the store exposed properties, but will get the needed information via a simple API. We could have used a delegate pattern instead, but as both blocks are essentially custom blocks in a custom app, there is not much need to define a protocol for their interaction. We can say that the controller part has been split in two parts, one for the UI, the shelf, and one for the back-end, the Store. Their link is such that the Shelf depends on the Store (strict link), not viceversa. Any Store to Shelf communication is done using lazy methods, based on notifications.

The app has then been integrated with the new Newsstand requirements in the info plist. Again have a look at Apple docs or my tutorial for a detailed guide.

Models and Controllers

We have one model in this app, it is the Issue model which represents a single magazine issue in the store or in the user library. There is also one controller, which is the Store. As I said this controller is not a UI component but the app back-end is self sufficient with these two components. In theory we can retrieve the store status and download magazines even without any user interface. This is a basic concept in magazine apps, where many events happen in the background are not related to direct user interaction: this means that the app should be capable to perform several tasks even if the user interface has not been loaded at all.

The role of the Issue class is to represent all relevant magazine properties, that is a unique identifier, a title, a release date, a link to the cover image, obviously the link (URL) to the content (which can be a pdf file, an epub file or a zip file for complex packages). In particular the unique identifier is a piece of data that must be maintained along the full life of the issue: it is the only way to uniquely identify a particular issue, independently of localization issues (e.g. the title can change in different countries, but not the unique ID). Besides it is the link to the Newsstand way to identify issues (the NKIssue‘s name field) and it can be also used to link the product with the App Store if we’re going to implement In App Purchases.

Other than this role, the Issue class will have a central role in the downloading of a magazine. Essentially the Store class will schedule a download but it will be monitored (progress) and then finished (effective magazine installation) by the Issue class.

Finally this class has limited capabilities to represent a magazine already downloaded and available in the user library. For this we provide the simple isIssueAvailableForRead that will be used by the user interface to know which action is possible with an issue (read or download) and eventually display the contents.

The Store class is the app controller. It is initialized at the very beginning of the app and its instance is never released. Besides immediately after initialization this class will fetch the store contents from the publisher server. In the example we decided to implement the store contents as a simple property list, and we instruct the store to retrieve this property list, decode it and create the Issue objects, and finally download their cover images. All this is done asynchronously using the Grand Central Dispatch and at the end a notification will be sent to inform all interested objects (in particular the view controller) that the store contents are ready and the UI can be safely displayed. Note that the store status is represented by a property status. We have overridden its setter method to post a notification that informs any interested observer of the new state. For simplicity we decided to limit the possible statuses to “not initialized”, “downloading”, “ready” and “error”. A more complex app can introduce extra states if needed. Finally as a fallback in case of missing connection (the user must be able to access his/her content even if not connected to the Internet) we reload a locally saved copy of the store.

The central piece of the code is in the downloadStoreIssues method of the class, that we report below:

-(void)downloadStoreIssues {
self.status=StoreStatusDownloading;
dispatch_async(dispatch_get_global_queue(DISPATCH_QUEUE_PRIORITY_HIGH,0), ^{
NSArray *_list = [[NSArray alloc] initWithContentsOfURL:[NSURL URLWithString:@"http://www.viggiosoft.com/media/data/iosblog/magazine/store.plist"]];
if(!_list) {
// let’s try to retrieve it locally
_list = [[NSArray alloc] initWithContentsOfURL:[self fileURLOfCachedStoreFile]];
}
if(_list) {
// now creating all issues and storing in the storeIssues array
[_list enumerateObjectsUsingBlock:^(id obj, NSUInteger idx, BOOL *stop) {
NSDictionary *issueDictionary = (NSDictionary *)obj;
Issue *anIssue = [[Issue alloc] init];
anIssue.issueID=[issueDictionary objectForKey:@"ID"];
anIssue.title=[issueDictionary objectForKey:@"Title"];
anIssue.releaseDate=[issueDictionary objectForKey:@"Release date"];
anIssue.coverURL=[issueDictionary objectForKey:@"Cover URL"];
anIssue.downloadURL=[issueDictionary objectForKey:@"Download URL"];
anIssue.free=[(NSNumber *)[issueDictionary objectForKey:@"Free"] boolValue];
[anIssue addInNewsstand];
[storeIssues addObject:anIssue];
[anIssue release];
// dispatch cover loading
if(![anIssue coverImage]) {
dispatch_sync(dispatch_get_global_queue(DISPATCH_QUEUE_PRIORITY_DEFAULT, 0), ^{
NSData *imgData = [NSData dataWithContentsOfURL:[NSURL URLWithString:anIssue.coverURL]];
if(imgData) {
[imgData writeToURL:[anIssue.contentURL URLByAppendingPathComponent:@"cover.png"] atomically:YES];
}
});
}
}];
// let’s save the file locally
[_list writeToURL:[self fileURLOfCachedStoreFile] atomically:YES];
[_list release];
self.status=StoreStatusReady;
} else {
ELog(@”Store download failed.”);
storeIssues = nil;
self.status=StoreStatusError;
}
});
}

Note that in the code above for simplicity I have queued the cover downloading immediately after the property list download. Probably this is not the best way to do this, as we are adding extra networking steps before presenting the app status, with possible delays if network conditions are not good. We can do this in an example where we know that the number of issues is limited, probably in a real app it makes more sense to do this in a background job and then notify the UI to update its status every time a new cover is ready to be displayed.

The view controller

The user interface will wake up immediately, and will change its appearance based on the notifications coming from the store. When the notification center will deliver the store “I’m ready” message to the UI, this one will load all UI issue representations (the CoverView class in the code, a basic view with really minimum application logic) and show the shelf to the user.

At this point the app terminated its back-end processing and is waiting for user commands. Here we have two possibilities:

  • A magazine has been downloaded, the user will see a “READ” button, clicking on it he will be able to read it. In our example all our content is made of pdf files, we decided to use the Quick Look framework in iOS, it is enough for our purposes.
  • A magazine has not been downloaded yet, the user will see a “DOWNLOAD” button, clicking on it the download will start and we’ll show a progress bar. At the end we need to replace the button label and hide the progress. We’ll see this part in more detail.

The view controller is dependent on the store. In order to get the issues information (number of issues, detail of each issue) it will not access directly to the store properties but will use a very simple API, made of three methods:

/* “numberOfIssues” is used to retrieve the number of issues in the store */
-(NSInteger)numberOfStoreIssues;/* “issueAtIndex:” retrieves the issue at the given index */
-(Issue *)issueAtIndex:(NSInteger)index;/* “issueWithID:” retrieves the issue with the given ID */
-(Issue *)issueWithID:(NSString *)issueID;

Based on this information, and on the Issue properties, it will create the Issue view representation (CoverView) and place it on the screen.

Downloading a magazine

In a magazine app there are three critical sections: retrieve and display of the store contents, download the contents and finally read them (a good PDF or epub reader is mandatory in an app like that; it’s not the purpose of this tutorial, aimed to explain the architecture and the techniques needed to make such an app, but it is a relevant part in the user experience).

My approach in the magazine download is that the user must be completely free to do any action and such actions shouldn’t interfere with the result of the download. Now many apps take a shortcut: they put a spinner in the center of the screen, then block any user interaction with the UI objects behind the spinner and ask the user to wait. It’s easy to do this, but it is not the better user experience. While waiting the user can read another issue, can navigate inside the store or decide to switch temporarily to another application or finally can temporarily lose the network. Newsstand Kit provides a system level methodology that simplifies (in some cases) the developer life but at the same time removes any excuse on not doing a good job in term of user experience.

As soon as the user triggers a new download, the view controller will send its download request to the store class. In the code below you can see the scheduleDownloadOfIssue: code. This method will prepare the network request and will send it in the background. Note how we split the app behavior based on the operating system version we’re on. If it is iOS5 then we must use the Newsstand approach – where the downloading will be managed by the system in a Newsstand queue – , if we are in iOS4 we’ll follow a classic methodology based on NSOperation: in this case I missed for simplicity to get the content length of the content to be downloaded, so in the iOS4 case the progress bar will not be displayed. This information instead if provided “for free” by Newsstand.

-(void)scheduleDownloadOfIssue:(Issue *)issueToDownload {
NSString *downloadURL = [issueToDownload downloadURL];
NSURLRequest *downloadRequest = [NSURLRequest requestWithURL:[NSURL URLWithString:downloadURL]];
if(isOS5()) {
// iOS5 : use Newsstand
NKIssue *nkIssue = [issueToDownload newsstandIssue];
NKAssetDownload *assetDownload = [nkIssue addAssetWithRequest:downloadRequest];
[assetDownload downloadWithDelegate:issueToDownload];
} else {
// iOS4 : use NSOperation
NSURLConnection *conn = [NSURLConnection connectionWithRequest:downloadRequest delegate:issueToDownload];
NSInvocationOperation *op = [[NSInvocationOperation alloc] initWithTarget:self selector:@selector(startDownload:) object:conn];
if(!downloadQueue) {
downloadQueue = [[NSOperationQueue alloc] init];
downloadQueue.maxConcurrentOperationCount=1;
}
[downloadQueue addOperation:op];
[downloadQueue setSuspended:NO];
}
}// iOS4 only
-(void)startDownload:(id)obj {
NSURLConnection *conn = (NSURLConnection *)obj;
[conn start];
}

In the two cases I’d like to emphasize the fact that the Store initiates the download operation but then it will delegate any further processing to the interested part, the is the Issue to be downloaded. So it will be the Issue class that will monitor the download and then will finalize it.

The Issue class will behave as delegate of the download operation triggered by the Store class. The delegate protocol changes if you’re using Newsstand or not. In the former case you will need to be compliant with the NSURLConnectionDownloadDelegate protocol while in the latter the protocol to be respected will be the un-documented (or: documented in the header files only!) NSURLConnectionDataDelegate which is a “spin-off” of the classic NSURLConnectionDelegate. The difference between the two protocols in that one will write in the file system, the other in memory. Again don’t use the “data” approach for production purposes, here we’re loading the whole content in memory and then saving on disk when the content has been completely downloaded: really not the best approach if your content is hundred of megabytes, your app will certainly crash.

In order to visually track the progress and then update the user interface, we decided, being coherent of our principles, to keep the application store controller independent on any UI choice. To do this we make use of KVO and Notifications. Essentially when the view controller starts a download, it will set itself and the magazine view as notification observers of the download result, in order to update its status as soon the download terminates (with success or with error):

-(void)downloadIssue:(Issue *)issue updateCover:(CoverView *)cover {
cover.progress.alpha=1.0;
cover.button.alpha=0.0;
[issue addObserver:cover forKeyPath:@"downloadProgress" options:NSKeyValueObservingOptionNew context:NULL];
[[NSNotificationCenter defaultCenter] addObserver:self selector:@selector(issueDidEndDownload:) name:ISSUE_END_OF_DOWNLOAD_NOTIFICATION object:issue];
[[NSNotificationCenter defaultCenter] addObserver:self selector:@selector(issueDidFailDownload:) name:ISSUE_FAILED_DOWNLOAD_NOTIFICATION object:issue];
[[NSNotificationCenter defaultCenter] addObserver:cover selector:@selector(issueDidEndDownload:) name:ISSUE_END_OF_DOWNLOAD_NOTIFICATION object:issue];
[[NSNotificationCenter defaultCenter] addObserver:cover selector:@selector(issueDidFailDownload:) name:ISSUE_FAILED_DOWNLOAD_NOTIFICATION object:issue];
[_store scheduleDownloadOfIssue:issue];
}

Both the cover view and the view controller will need to unregister from the notification center as soon as the download operation terminates. Besides to allow the cover view to keep track of the progress status, as the download starts it will be registered as a KVO observer of the downloadProgress property of the Issue. This means that for each change of this property, that will occur during the downloading phase, the cover view will be informed of the change to update the progress bar (so we have here a separation again of the back-end property, the download progress, from the UI, the UIProgressBar). The cover view will unregister itself as soon as download terminates.

When the download terminates, the Issue instance will copy the downloaded content to the final destination. In the Newsstand framework this destination is specified by the system, in iOS4 will copy it in the Caches directory to be compliant with iCloud requirements (yes, iOS4 doesn’t work with iCloud but our app is the same for both generations of the OS, so we must be good citizens in any case).

In the Newsstand case we’ll also need to update the cover image for the Newsstand icon. We’ll do it with a simple command inside the code that manages the download termination (at the end we also send the end of download notification we mentioned previously):

-(void)connectionDidFinishDownloading:(NSURLConnection *)connection destinationURL:(NSURL *)destinationURL {
// copy the file to the destination directory
NSURL *finalURL = [[self contentURL] URLByAppendingPathComponent:@”magazine.pdf”];
ELog(@”Copying item from %@ to %@”,destinationURL,finalURL);
[[NSFileManager defaultManager] copyItemAtURL:destinationURL toURL:finalURL error:NULL];
[[NSFileManager defaultManager] removeItemAtURL:destinationURL error:NULL];
// update Newsstand icon
[[UIApplication sharedApplication] setNewsstandIconImage:[self coverImage]];
// post notification
[self sendEndOfDownloadNotification];
}

Conclusions

This is the conclusion of this tutorial. We decided after a long interval to make an effort to propose a complete app valid for both iOS4 and iOS5 environments. In the code you will find more interesting stuff, e.g. a “hook” to the Store Kit: this is a typical issue not considered by developers when they make applications that sell magazines. In such case storing the issue price in the publisher server is not of help as we must retrieve the pricing information from the only relevant source, that is the App Store. To do this our app must – asynchronously – query the iTunes store for the prices of all the publications and then display them once retrieved. I’m not adding this extra step in the code, just the hook as placeholder for future extensions, but of course if required by our readers I can extend this tutorial further. I would appreciate any suggestion and any contribution in the GitHub hosted code, I would like to see the example code provided with this tutorial as a good skeleton for new apps. If you didn’t enjoy this article, at least you can enjoy the literature classics (and a Django manual…) that I used to create my PDF files.

Carlo Vigiani

 

I3Factory LLc World has published a new app with owr i3F Editorial System:
The most simple and usefull system of owr Developing department.

Avaliable su App Store

http://itunes.apple.com/app/id455225634

Introduction

One of the most appreciated features by iPad users is the possibility to read books, magazines and newspapers. Practically all major publishers are in the App Store with apps dedicated to their products but there also many other minor publishers, in every country, that entered in the iOS world with one or more apps.

Applicazione iPad per riviste e Magazine

Developing iPad App for Magazine

Today a publisher that wants to enter in the App Store with his own magazine has several decisions he needs to make. Some of these are:

  • is it better to publish a specific app for the magazine or use a newsstand app as Zinio?
  • in case we decide to use our own app, should we contact an iOS dev to have a tailored product or use a web-based service that provides us in short time with a standard app?
  • should the magazine service be hosted by a third party or by the publisher itself?
  • is it better to re-use existing PDF or make a completely new digital magazine (e.g. if you use the Adobe Digital Publishing suite)?

Of course all these decisions will have impact on development costs, web services hosting and maintenance and finally the magazine design flow.

The author of this post has gained some experience by developing and releasing on the App Store several magazines.This series of articles is based on the experience acquired by developing some custom magazine apps and will try to depict what is the architecture of an iPad magazine app starting from the building blocks and entering into the coding challenges occurring on these blocks. We hope that any developer that should have the chance to build an iPad app can take some benefit reading these articles.

Part 1 – Architecture

The scheme below shows the three main screens of a typical magazine app.

note:Even if we’ll mainly refer the iPad device, all considerations can be applied to the iPhone too.



Main screens of a Magazine app

The first screen is the Store screen. This is typically the first view presented to the user (with the exception of the splash screen if required by the publisher) and provides the user the list of all issues that are currently available for purchase (with the term “purchase” we also mean “free” issues, which obviously are zero-priced).

note:In a typical magazine app we have only one kind of magazine, so the choice will be restricted to the last available issue and a set of older issues.

Of course for a more complex app, e.g. a book seller or multi-magazine app, this screen could be more complex as in such case products are organized by categories and then we could have a hierarchical representation of the same screen. Typically issues are represented with their cover and these covers are shown as a grid, or as a scrolling stand or using the well-know “coverflow” effect.

Together with the cover each issue is classified by its name, its release date and of course the price represented in the user currency. Besides a set of actions are associated to each issue, typically: purchase, download, preview.
Once an issue has been purchased, it should be automatically transferred to the Library view. This screen (which is usually accessible using the tab bar at the bottom) will show the list of issues that have been purchased. From this view the user can, for each issue, decide to read, delete, archive or download it.

Finally the Reader is the part of the app that allows the user to view the magazine: it can be a general purpose PDF or e-pub reader, or use (but this is not recommended as the capabilities are quite limited) the system Preview feature or finally be a custom reader: this depends on the format the issues are downloaded by the app.

Some publishers may ask to merge the Store and Library sections: this is a natural choice for those magazines which have a monthly (or lower) periodicity: in such case – due to the low number of issues available – it could be easier to show all covers in the same screen providing to the user different actions according to the fact that the magazine has been purchased or not.

A magazine app with the right architecture should be able to decouple the visual structure from the functional blocks. The reason for this is that both the publisher and the UI designer could come out with completely new ideas on how to represent the store on the screen, and it would be a nightmare for the developer to integrate each time his own back-end code with the specific needs of the new user interface. So to guarantee the maximum re-usability of the Store Manager and modeling structure it is good idea to architect the app following the MVC (Model View Controller) pattern as recommended by Apple for Cocoa apps.

Below you can see a high level functional blocks diagram.

The Publisher Server cloud symbol in the diagram represents all internet services, which are not part of the app. Normally this includes the server infrastructure used as storage for the magazines and the set of web services that will provide the magazine information to be seen on the store. This back-end can be hosted on the customer owned servers, or on specific sites such as Amazon S3 or finally on the developer server (but in such case be careful to provide a sufficient bandwidth and minimum downtime).

The Store Manager block is the central functional piece of the app. Its role is to communicate with the back-end server(s) and dispatch acquired data to the other parts of the app.

Initially the Store Manager needs to fetch from the back-end service the list of all available issues. How this can be done is specific of the implementation. We can use a simple XML or JSON file in case the list of issues is not huge, or we can establish a more complex protocol in case the publisher catalog is too large to be downloaded each time. E.g. we may provide access to several magazines which are organized by category or implement a search feature.

noteThe communication between the server and the app is one-way as data is transferred from the server to the app while the opposite flow could be limited to a minimum data exchange consisting of purchase transactions, simple http queries or analytics on the app usage.

From the point of view of the developer it makes sense to insert an intermediate communication layer (not shown in the diagram) between the server and the Store Manager: the advantage for this is that the Store Manager will expose a set of simple and general purpose APIs and at the same time the communication layer will take care of the specific implementation of back-end APIs.

Each time a new bunch of data is sent from the server to the Store Manager a set of Issue Models is created.

An Issue Model is the logical representation of each issue, and it consists of a unique identifier, the title, a cover image and the release date. Other information can be provided according to the application characteristics: e.g. a set of image previews, a short description of the issue, a table of contents, etc.

note:It is important to note that the Issue Model is characterized by a set of fields and only a subset of these is assigned by the store. Other information can be acquired from other sources: e.g. the price can be retrieved from the In App Purchase system, or the information that the product has been already purchased and downloaded from a local repository in the application data area. That’s why in the diagram below we decided to attach the Issue Models representation to a Local Storage block.

As soon as a new Issue Model is created by the Store Manager, it is annotated with few extra info collected from the Local Storage. The natural choice for the Local Storage would be to use the Core Data framework but of course a more simple approach based on plists or a serialized version of the data model.

The Store View is a view controller dedicated to provide the Store UI.

note:While the Store Manager is a highly reusable component, the Store View is customized according to publisher requests: we can have a shelf view (as in iBooks) or a sliding covers view, or a cover flow effect. In order to decouple the model data from the view the Store View can talk with the Store Manager using a delegate protocol.

Besides the Store View needs to listen to some Store Manager changes using a central notification mechanism or key-value observing (KVO). Why this requirement? because even if in most cases the Store View gets its data by querying the Store Manager block, using its delegate protocol (e.g. number of categories, name of categories, number of issues per category, name of issues, cover image and so on), it may happen that some events occur asynchronously with respect to the typical UI interaction (e.g.: a user is reading an issue but at the same the app finish to download another issue): in such case the Store View controller must be informed of this particular event in order to update the UI appropriately. Once the Store View knows, through notification or by KVO observation, that something changed in the Store Manager, it can start the delegate protocol based query cycle to update the UI.

The Library View is also a View Controller which is similar to the Store View but customized for the purpose of displaying only issues that have been purchased. It still needs to communicate with the Store Manager using the same protocol used by Store View and it still needs to listen to Store Manager changes, but the set of actions available to the user is completely different. As soon as a purchase is done, that is the transaction has been recorded, there are a set of operations that could be deferred or could simply fail due to temporary networking issues: they are the download phase (which could take several minutes especially if the issue a several hundred megabytes package) and the installation phase (typically unarchiving the package, generating thumbnails and so on). So the Library Manager needs to expose to the user the next required action: download, if the issue has been purchased but not downloaded, stop/cancel download if issue download is in progress, install if the package has been downloaded but not installed and finally read to start reading the magazine.

In the diagram we kept the Store and Library views separated to emphasize the different requirements and to be coherent with the 3-screens based app organization. But as stated before it may happen that the Store View and the Library View are merged in a unique view controller; this approach is common to many well-known magazine apps in the App Store.

note:The Store Manager maintains an interaction with two internet-based Apple services: In App Purchase (via Store Kit framework) and Newsstand (currently in beta, will be available with iOS5).

Due to App Store rules, In App Purchase is practically the only way to purchase magazines from the store. As there is no way at the moment to let the publisher own back-end server to communicate directly with the In App Purchase system, the Store Manager block must be able to annotate the Issue Model with the extra pricing info coming from the In App Purchase server.

The recommendation in such case is to insert an intermediate layer between the Store Manager and the Store Kit framework, whose purpose is to manage the communication with the highly asynchronous Store Kit protocol thus giving at the same time a simple interface to the Store Manager (e.g.: is this issue available in the store? what is the current price in this country? did the user already purchased the issue?) One example of well-known and excellent layer is the MKStoreKit open-source library available from GitHub.

Newsstand is a new feature coming with iOS5. As we are constrained by the NDA with Apple, we cannot disclose too many details and just refer to the marketing info available in the Apple web site. Essentially Newsstand will be a central hub for all subscription-based magazine apps: it is a special Springboard folder that will collect all information from the magazine apps and show and download all the latest issues. The Store Manager must provide the minimum required interface to provide the app the compatibility with this new feature.

In the next articles I will provide some more detail about the construction of the different blocks. We’ll see the details of the Store Manager delegate protocols, we’ll discuss the model behind each issue and we’ll see how to efficiently retrieve information from the network.

 


Introduction

One of the most appreciated features by iPad users is the possibility to read books, magazines and newspapers. Practically all major publishers are in the App Store with apps dedicated to their products but there also many other minor publishers, in every country, that entered in the iOS world with one or more apps.

Today a publisher that wants to enter in the App Store with his own magazine has several decisions he needs to make. Some of these are:

  • is it better to publish a specific app for the magazine or use a newsstand app as Zinio?
  • in case we decide to use our own app, should we contact an iOS dev to have a tailored product or use a web-based service that provides us in short time with a standard app?
  • should the magazine service be hosted by a third party or by the publisher itself?
  • is it better to re-use existing PDF or make a completely new digital magazine (e.g. if you use the Adobe Digital Publishing suite)?

Of course all these decisions will have impact on development costs, web services hosting and maintenance and finally the magazine design flow.

The author of this post has gained some experience by developing and releasing on the App Store several magazines.This series of articles is based on the experience acquired by developing some custom magazine apps and will try to depict what is the architecture of an iPad magazine app starting from the building blocks and entering into the coding challenges occurring on these blocks. We hope that any developer that should have the chance to build an iPad app can take some benefit reading these articles.

 

Sistema editoriale per piccoli medi e grandi editori che permette di pubblicare quotidiani, magazine, riviste ed altro utilizzando i documenti pdf dell'editore. i3F Editorial inoltre e' un'investimento minimo una tantum , una volta sola, e nn necessità di manutenzione e/o costi aggiuntivi. Tutto resta all'editore.
Publishing system for small, medium and large publishers Editorial i3F and also ‘an investment lifetime, once. Everything stays the publisher.

The starting price for our solution starts from 200 euros for small Authors, a customized solution for publisher wishes ,that contains all the features necessary for most small-medium-sized publishers, starts from 900 euros for medium Publishers and starts from  € 2000 for medium and large publishers.

We are also willing to consider solutions “Full Custom Made” for publishers who need to customize and adapt their models.

For Public Market solution Go on  i3F Editorial web site (http://i3factory.com/editorial)
Examples of App Publish with i3editorial:
(Note our customer pays no maintenance or costs both fixed and variable after the publication of the app):

Farmamese, rivista magazine sistema editoriale iPad iPhone & Android i3editorial.com

Farmamese