• Italiano

Increasingly, our customers and readers submit proposals for developing an app without using standard documents and without using those terminologies that may help to understand properly how many and which features should have given the app.

If you want to convey an idea that allows you to create an app for iPhone, iPad or Android is necessary to prepare a clear Mockapp and / or Functional Document which will contain all the detailed features of the app for your iPhone or iPad or Android together with a layout that makes understanding the User Interface and User Experience.

Cooker App – Design, Mockup e Prototype Apps interfacce app in iOS

If you want to use your iPad as a tool to prepare the mockapp prototype, we mark App Cooker (website: http://www.appcooker.com/).

We will report instead of in the next article on what are the tools that you can use with your Mac or PC.

Many people have abandoned almost entirely the use of computers and rely on the iPad to send emails, take advantage of the Internet and use tools;

App Coocker  is an app for iPad and consider it a great tool if you want to bring your ideas to a stage of possible realization.

App Cooker, is present in the App Store at a price of € 15.99, which according to some rumors will increase to $ 24 the next version, the application (IPAD) is developed by HotAppsFactory and, as we have said, used to design applications iPhone and iPad ..

The ‘App Board will collect your conceptual plans, mock-ups, icons, App Store and pricing strategy.
It will be the backbone of your project and lets you work in an organized and clear.

Below is a video in English directly from the official site:

Define the ideas

We start with an idea, a sketch and use this app to organize the ideas and inspire.
The idea is the essence of any application and it requires time and careful consideration.
App Cooker provides a dedicated tool for this, providing valuable advice set out by Apple and other industry professionals.

iOS MockupiOS Mockups

The engine mockup supports orientation, simple links and unites assim the UI of Apple (UI) design with bitmaps, vector shapes, text and images.
Prototypes can come to life, without a single line of code.

The ‘trademark icon of the app

The icon is the face of your application. The creation of large icons requires experimentation and several attempts until the solution will not be found. Using the freehand tool, or images with vector shapes you can define the look of the icons of your ideas and see the results in various sizes and in no time.

Prices tool
App Cooker allows you to compare a large number of price scenarios to find the right model for your application. Supports both purchases app that advertising, which makes it easy to predict revenues, costs and profits.s

Descriptions App Store

Descriptions App Store

The description on the product page of iTunes is a deciding factor for potential buyers. App Cooker makes writing this information a simple task, and provides a place to locate in any of the App Store in 18 languages​​.

Mockapp before to the development of code

Designing a good application is difficult. You must have creativity, talent, resources, knowledge, time and a strong sense of self-criticism; the app to succeed are the result of a long process of refining.

We spent a long time, with many different clients and companies who contact us, to try to explain the best way to design applications for iPhone, iPad and Android.

With all the time, sooner or later discover that the design of an application is much more than just graphic design.

Below we enunciate the 10 principles that I have collected from the site of the App cooker:

In conclusion,

Cooker app is configured as a professional application, since it allows to design all the elements of an application compatible with all Apple devices IOS.

Addressing all those who intend to develop their own application, you must first make clear the initial idea, compatibility with various devices and various functions, then we must create the various graphic elements of the mockup, the icon , location on the App Store and deployment prospects and earnings.

Below we enunciate the 10 principles that I have collected from the site of the App cooker:

• Italiano

HTML(5) Approach
The final technique is something that is emerging now, especially thanks to the great improvements in term of stability and speed introduced by the latest version of iOS for the in-app web views. A couple of good examples of this approach are the Ars Technica app (link) and the Bloomberg Businessweek+ magazine (link).

The concept is quite simple: html and css are common and powerful techniques to layout a page on screen: why not leverage the skills developed by many web designers to make a magazine that perfectly fits with the iPad?
The core block at the base of this approach is the UIWebView Cocoa Touch object: with this view we can load any kind of html document, loaded locally or remotely, and layout it in the page at an adequate speed (but not the fastest) and without surprises. Besides we can get rid of the overlay
technique, as the web view is capable of displaying images, playing movies and of course execute javascript based widgets. Also this component provides a two way interaction between the javascript world and the objective-c runtime (and in fact this justifies the existence of extension languages
such as Objective-J, provided with the Cappuccino framework: http://cappuccino.org/). Finally the web view is highly respondent to user interactions, and some features like text selection and dictionary lookup come for free.
The open-source world is highly active in this area: projects like Baker (www.bakerframework.com), Siteless (www.siteless.org), Laker (www.lakercompendium.com) and pugpig (pugpig.com) make publicly available this kind of solution.

Sincerely we don’t know if this will be the final solution for everybody. Of course a publisher that already invested in setting up a web site (but not in Flash!), and this is quite common between newspapers, will be able to port most of the layout and contents to the iPad, and sometimes this can
be achieved with an adaption of the CMS output views to provide files that can be easily fed to the app.

Careful must be given to don’t push this behavior at its extremes: don’t forget in fact that web page rendering requires an inner engine and at the end any intermediate layer will require resources and extra time. Sometimes, and this is particularly evident with the first generation of the iPad, content
updates following user interaction are not very reactive. So it is not recommended to transform every single aspect of the magazine app into web based content: clearly in this way you’re helping all javascript developers not skilled with objective-c, but
a performance penalty will be visible.

As an example, the toolbar typical of all magazine apps used to access extra features (sharing, table of contents, home page, etc.) should always be done using the native Cocoa Touch component and not an html+css solution.

However if the publisher accepts to convert his design flow to a web based one and you, as developer, prefer to base your work on consolidated and easy to manipulate methodologies, this one should be your first choice to be taken in consideration.

Conclusions
We hope this article gives a good overview of the major techniques used to render pages in a magazine, newspaper or e-book. It could be we have not mentioned some technique we’re not aware of, in such case dear reader any feedback from you is welcome!

About the author: Carlo Vigiani
He is an electronics engineer and software developer, located in Italy. He is CTO and co-founder of new startup i3Factory.com, active in the development of iOS, Android and Win Mobile apps, with special focus on publishing, tourist and music apps.

Source: www.icodermag.com

01/2012

• Italiano

Pages Pre-Rendered by images
This technique is heavily used inside the highly interactive magazines published using the Adobe Digital Solutions environment: well known examples are the Condé Nast magazines (Wired is one of the most famous examples).
The way these magazines are implemented starts with the well known suite of Adobe Digital Publishing tools, In Design in primis. These tools are used by many publishers around the world and the latest versions offer the pos sibility to export the project, other than in the ubiquitous pdf format, in a package suited for distribution through iPad. The output of these files can be tested using the free app Adobe Content Viewer downloadable from the App Store, but of course the final branded app, together with the server infrastructure required to serve the contents, requires a higher tier license.

What characterizes this kind of magazines is that at the moment of project creation all pages are pre-rendered as jpeg or png images and then special effects are overlaid.
This means that the core section of the magazine reader is essentially an image viewer. Sure these images will span an area slightly larger than the iPad screen, so they will be embedded inside a scroll view, but they are still images. All in all technically the choice is not bad: the iPad is quite better in rendering images than PDF files, as the required calculations needed to transform the pdf data in bitmaps is completely skipped here, while the CPU will just need to decompress the image and send it to the graphics hardware. Exactly as we did in the PDF case, we can apply the overlay technique to over impose somecontent that requires user interaction on top of the bottom rendering layer.

While this technique is highly efficient from the point of view of rendering time, and is simple to implement as all the page layout complexities have been taken into account and solved by the desktop publishing tools, it offers a few limitations that need to be considered:

•     every single page takes quite more space on disk and download time of this kind of magazines is increased correspondingly; in comparison with a pdf page, the space taken is much more as every pixel of text must be provided in the file and we cannot force high compression ratios if we don’t want to introduce blurring in the text. The pdf page, especially those pages made of text only, is much lighter as the text is not pre-
rendered.

•     zooming or font resizing is not feasible: both pdf and core text redraw the text using vectorial algorithms or per-size font representations, this is not possible to achieve on a static image. This means that the magazine needs to be drawn with specific fonts types and sizes, fonts which are well suited for jpeg compression (no blur) and the screen resolution (132 dpi, not so high; things will be better with the next retina display iPad!)

•     text search, highlight and selection is impossible, unless the digital publishing tool exports together with the pre-rendered pages a full map of text coordinates, something I haven’t seen yet!

Adobe is not alone in publishing this kind of magazines:
there are several custom apps in the market that follow exactly the same approach. It’s not bad but is not leveraging the great publishing frameworks that Apple is offering to its developers. And it has too many limitations if compared with other techniques. For sure a publisher that is mastering the digital publishing tools I mentioned before can take advantage of this approach, as the final quality is undoubtable and the time to market is the shorter, and at the same time allows to provide a content suited for the iPad, and not just a pdf fit on screen.

But I would recommend to all developers that are making custom products and are not using specialized page composition tools to stay away from such methodology.

Source: www.icodermag.com

01/2012

• Italiano

CORE TEXT RENDERING
Core Text (short: CT) is another of those technologies developed for the Mac and later ported to iOS.
The Core Text framework is dedicated to text layout and font handling. Just to summarize the capabilities of this framework, consider that is at the base of the desktop publishing revolution that made the Mac famous in this professional sector.
As CG, even CT has a C-based API, even if there are several third-party open source wrappers that pack together the most common functionalities in a high-level Objective-C interface.

CT should not be used to replace web based rendering based on html and css, this is a too complex field that is better to leave to dedicated system components such as then UIWebView instead it can be used to efficiently render some rich text.

CT talks with CG, in fact text rendering is done at the same time of view Quartz based rendering. The two APIs have similar conventions and memory management rules, so the developer already accustomed with Core Foundation programming model will not find an hurdles in understanding the CT API. This gives the possibility to the developer to eventually mix the text rendering and image drawing at the same rendering stage (CT is limited to text only, it has no image drawing capabilities).

The main reason to use Core Text is because it does direct rendering of text on page without any intermediaries. It differs from PDF which consider each page as a whole, it differs from web based techniques as there is no intermediate language (html) or layout interpretation (css) in between, you can write directly on the page. The basic components behind CT are layout objects such as “runs”, which are direct translation of characters
into drawable glyphs, “lines” of characters and “frames”, which correspond to paragraphs. The translation of characters to glyphs is done by “typesetters” and the text to be plotted is provided using attributed strings, which are common strings enriched with attribute informations (font size, color, ornaments).

You will decide to use Core Text for a magazine whose layout will be mostly based on text with standard layout, so it fits well for newspapers also. Probably it’s not the best choice for glamour magazines where graphics layout is changing on every page and could be quite complicated.
A clear advantage of the Core Text based solution is that you don’t need to apply the overlay technique we mentioned in the paragraph dedicated to pdf. With CT you will directly divide your page in frames and each of these frames will contain text (rendered by CT) or multimedia. Essentially you can define the page layout by selecting a size (it can fit the iPad screen or it can be vertical or horizontal scrolling page), then you will decide the size and position of media content in this page and finally you will define the frames (several rectangular frames) that will contain the text. The text frames organization can be of any kind, from compact single column structures, two multicolumn layout or varying size frames. Inside the frames you will render the text and Core Text will help you to manage line breaks for these paragraphs. Then you can easily provide the user the possibility to change font type and size and the same rendering code can be reused to quickly rearrange the text inside the frames.

The page layout representation can be provided in any form decided by the developer together with the publisher, the best choice will be XML (all in all it’s the base of any markup format!) and it will be shipped to the app together with the texts (still XMLs) and the assets in a zip file package.
One limitation of Core Text is that it is a text drawing technology and is not optimized for editing (but we don’t need it at this stage) and user interaction. This means that if we want to provide text highlight or select and copy features we’ll need to implement them by our own; the framework provides us some APIs to facilitate this task but in any case the code to implement these functionalities must be written by the developer to manage every single detail. In any case all these tasks will be greatly simplified in comparison with PDF: here you have full control of the text and its position of screen, while pdf is still an opaque entity hidden behind a complex data structure that you cannot control in its entirety.

Our recommendation is that if you must implement a digital magazine, without extreme layout requirements, some multimedia content and a fast and powerful control of text, using Core Text is the first technology choice to be considered.

An excellent tutorial on the subject is available at this link on Ray Wenderlich blog: http://www.raywenderlich.com/4147/how-to-create-a-simple-magazine-app-with-core-text

Source: www.icodermag.com

01/2012

• Italiano

The Magazine is a PDF File
You may like it or not, but should your software house be committed to develop a magazine iPad app, the magazine will be with high probability given to you as a PDF file. As there is no way to “escape” from it, at the end you will need to develop your own pdf reader or integrate some free or  commercial external library.
The reason why pdf is still the dominant format in the e-publishing world is clear: most of the publishers are porting their existing printed  publications on the iPad, and for obvious budget reasons they want to reuse all the investment done in the creation of their issues. You will not be able to escape from the pdf format dictatorship with the exception of two cases: the publication is brand new and only digital, so there are no previous investments to drive the final choice, or the publisher has large budgets and/or is a strong user experience (UX) believer and accepts to allocate the extra budget to recreate a different format for its publications. Both cases are not so uncommon with those publishers that already did the effort to bring their products to the web (with the notable exception of those that did it in Flash!), but the large part of the small and medium publishers will
still be locked to the pdf format.

Unfortunately the pdf is not the best way to port a magazine in the iPad. And this for several reasons:

•     printed magazines page size is usually larger than the iPad screen: this means that when the page fits to the screen, all characters appear smaller and then something readable in the printed paper could become unreadable without zoom; but zoom is not always efficient and in particular it’s not loved by readers that may lose their “orientation” inside the page.

•     printed magazines pages have not the same aspect ratio of the iPad screen: this means that a page that fits in the screen will be bordered by top/bottom or left/right empty stripes.

•     often printed page layouts are optimized for facing pages, e.g. a panorama picture which is spread between two pages; when the device is kept in portrait orientation, these graphical details will be lost, instead if the device is kept in landscape you will be able to appreciate the two-pages layout but characters will be too small to be read comfortably.

•     as these files are not optimized for digital, normally the outlines (table of contents) and annotations (links to pages or external resources) are not exported; this means that even if your pdf reader code is aware of this information, in the majority of cases it is not available and then you will need to define a different way to provide it.

•     the official pdf format supports multimedia content; unfortunately the iOS is not able to manage it, so all interactive content must be provided  outside the pdf file.

The page rendering is achieved in iOS (and OSX too) through the Quartz 2D API, provided within the Core Graphics framework (shorted with CG). Quartz 2D is the two-dimensional drawing engine on which are based many (but not all) of the drawing capabilities of iOS. The
PDF API is a subset of the huge CG API. This API is “old fashioned” and is not based on Objective-C but on pure
old C; besides all memory management rules will follow the Core Foundation (CF) rules which are different from Obj-C one: this means that special attention must be provided to avoid memory leaks, as each PDF page manipulation can take several megabytes and leaks will easily trigger the memory watchdog, thus force quitting your app.

be immediate to render a PDF page, by following these basic steps:

1. get the CG reference to the pdf page to be drawn;
2. get the current graphics context for the view that will contain the page;
3. instruct Quartz to draw the pdf page to the context.

As you can see, apart the required steps needed by the drawing model of Quartz, the full rendering is accomplished by the system and you don’t need to have any knowledge of the data format of a pdf file. So for you the pdf rendering processor is just a black box, and this is clear when you
see that all CG data structures are in fact opaque and their inner contents can be accessed only via API.
But a valid pdf magazine reader cannot limit itself to rendering, so you will be required to support zoom. Now as your maximum zoom level can be theoretically very high (don’t forget that characters in the pdf file are like fonts in the computer, they will never lose in precision even for
extreme zoom-ins), it is impossible to render the full zoomed page in a canvas much higher than the device screen:
here we have pixels, not vectors, and it would be immediate to crash the app because all the memory has gone away for one page only. So you will be forced to introduce tiling techniques that will limit the effective rendering to the visible part of the page, not always an easy task.

More difficult is document parsing: this is required if you want to extract outlines, annotations, do some text search and highlight. In such case apart a few meta data extraction functions, what the API gives you is a set of functions that will allow you to explore the data structures inside the document. You will not be able to get any information from the file if you don’t explore the data tree correctly and if you don’t follow the specs of the PDF document.
This is worsened by the many versions the PDF specs got in the years and by the fact that many publishers still use old software that exports the  content in the old formats.
I have developed a general purpose PDF explorer, this was part of a commitment of a client that asked me to develop a general purpose PDF reader; but as it is really hard to apply all the specs of the PDF official reference, my suggestion is to concentrate on the most used features and test them with many documents. As I said before, CG navigates the data tree but it doesn’t interpret it for us!

The last section of this part, long explanation but required given the importance of the topic, is how to provide multimedia content on top of a PDF file: all in all the iPad is a so versatile device that we cannot limit ourselves to simple page rendering. By adding extra content to the printed page you can leverage the device characteristics and still taking benefit on the investment done in the magazine creation.

There are many reasons to justify this choice: e.g. a printed advertisement can offer a video instead of a static picture, or a printed link to a web page can be replaced by an active link to a web view, or finally we can show the current weather using an html5 widget. As I previously said it is not recommended to introduce all this content inside the pdf file: it will not be rendered by Quartz and you will still be forced to traverse the data tree to extract the CG object reference for further manipulation. Finally not all publishers are aware of these functionalities or their digital publishing software is too old to fully support them.

So the best solution is based on the “overlay technique”.
This methodology consists in representing the pages in two layers:

•     the bottom layer (“rendering layer”) will contain the PDF rendering, so it will contain the bitmap image of the page;
•     the top layer (“overlay layer”) will draw all overlays and is sensible to user touches.

The overlay layer is typically made of UIKit components, so we’ll add a UIWebView for html widgets, we’ll introduce a UIScrollView to display a gallery of sliding images, or we’ll add a Media Player view for video execution. Typically the overlay descriptions are provided on a separate file, e.g. an xml, json or plist, and they will be packed together with the pdf file and all assets (movies, images, html files, music
files) in a zip file.
The app will download the zip file, will unpack it and then for each page it will use the pdf page to fill the rendering layer, and the overlay information associated to that page to build the overlay layer.
Note that this technique can be applied also in the other rendering techniques we’ll talk about in the next paragraphs, in such case it allows to overcome many of the pdf format limitations. The major requirement for the deve loper is to define a suitable format, follow all page zoom
and rotations with a corresponding overlay transformation and finally provide the publisher with the instruments and
guidelines required to easily create such overlays.

source: www.icodermag.com

01/2012

• Italiano

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

• Italiano

Translate original post with Google Translate

Come abbiamo segnalato nel precedente articolo  di seguito trovate le principali caratteristiche di “Ice Cream Sandwich“ , dal punto di vista dello sviluppatore. Abbiamo tradotto alcuni importanti passi dal portale Android developer sul nuovo Os mobile Android 4.0,  che presenta importanti novità per il developer.

Unified UI framework per i telefoni, tablet e altro

Android 4.0 possiede una struttura unificata per l’interfaccia utente. L’Unified UI  framework include tutti gli elementi dell’interfaccia gia presenti in Android 3.x e API , così come nuovi elementi e le API.

Per gli sviluppatori, il framework di interfaccia utente unificata (Unified UI  framework) in Android 4,0 significa lavorare su nuovi strumenti di interfaccia utente con un metodo di progettazione coerente, codice e risorse semplificate e lo sviluppo diretto su tutta la gamma di dispositivi Android che istallano Android.

Comunicazione e condivisione

Android 4.0 estende le caratteristiche sociali e la condivisione di tutte le applicazioni presenti sul dispositivo. Le applicazioni possono integrare con i contatti, i dati dei profili e gli eventi nel calendario da qualsiasi attività dell’utente o social network.

Le principali API sono:

• Social API
• Calendar API
• Visual voicemail API
• Android Beam
• Modular sharing widget

New media capabilities

Low-level streaming multimedia
Android 4.0 possiede un diretto ed efficente percorso per il low-level streaming multimedia. Questo risulta ideale per applicazioni che necessitano un completo controllo sui media data prima di passarli alla piattaforma per la  presentation. A esempio, mediae  applicazioni possono ora ricevere dati da qualsiasi fonte, applicare  encryption/decryption proprietarie, e quindi inviare i dati al sistema per mostrarli.

Supporta il format multiplexed stream per audio/video in MPEG-2.

Per ll supporto a questo low-level streaming, viene introdotta  una nuova API nativa basasta su Khronos OpenMAX AL 1.0.1.
Questa API è implementata su gli stessi servizi di base della piattaforma esistente OpenSL ES API, così gli sviluppatori possono usufruire di entrambe le API insieme, se necessario. Strumenti di supporto per lo streaming multimediale di basso livello saranno disponibili in una prossima release del NDK Android.

Nuova caratteristica della telecamera

Gli sviluppatori possono usufruire di una serie di nuove funzioni della fotocamera in Android 4.0. ZSL esposizione, messa a fuoco continua, e lo zoom dell’immagine permettono alle vostre apps di cogliereal meglio le immagini statiche e video, anche durante la cattura video.

Media effects per trasformare le immagini e video

Un insieme di filtri di trasformazione ad alte prestazioni  consentono agli sviluppatori di applicare effetti  a qualsiasi immagine che viene  passata come una texture OpenGL ES 2.0. Gli sviluppatori possono regolare i livelli di colore e luminosità, cambiare sfondi, affilare, ritagliare, ruotare, aggiungere la distorsione della lente, e applicare altri effetti. Le trasformazioni vengono elaborate dalla GPU, quindi sono abbastanza veloci per l’elaborazione dei frame immagine caricate dal flusso di disco, una fotocamera o video.

Audio remote controls

New media codecs and containers

Android 4.0 aggiunge il supporto per ulteriori tipi di codecs e containers per permettere agli sviluppatori di accedere ai formati di cui hanno bisogno. Per le immagini di alta qualità compresse, il media framework aggiunge il supporto per i contenuti WebP. Per il video, il framework ora supporta lo streaming di contenuti VP8. Per il multimedia streaming, il framework supporta i protocolli HTTP Live streaming versione del protocollo 3 e la codifica di ADTS-contained contenuto AAC. Inoltre, gli sviluppatori possono ora utilizzare Matroska container per Vorbis e contenuto VP8 .

Nuovi tipi di connettività

• Wi-Fi Direct
• Bluetooth Health Device Profile (HDP)

Nuove UI components

• Layout enhancementse
• OpenGL ES texture views
• Hardware-accelerated 2D drawing

Tutti i dispositivi  con sistema operativo Android 4.0 devon osupportare un’accelerazione hardware per il disegno 2D. Gli sviluppatori possono trarre vantaggio da questo per aggiungere effetti all’ interfaccia utente, pur mantenendo prestazioni ottimali su schermi ad alta risoluzione, anche su cellulari. Per esempio, gli sviluppatori possono contare su scaling accelerato, la rotazione e altre operazioni 2D, così come i componenti dell’interfaccia utente accelerati come TextureView e le modalità di composizione come il filtering, blending, and opacity.

New input types and text services

• Stylus input, button support, hover events
• Text services API for integrating spelling checkers

Android 4.0 consente alle applicazioni di interrogare i servizi di testo disponibili, come dizionari, spell checker,  suggerimenti per le parole, correzioni, e dati simili. I servizi di testo sono esterni al IME attivo, per cui gli sviluppatori possono creare e distribuire dizionari e motori di suggerimento che si inseriscono nella piattaforma. Quando un’applicazione riceve i risultati di un servizio di testo – per esempio, suggerimenti per le parole – che possono essere visualizzati in una finestra popup dedicata al suggerimento direttamente all’interno della vista del testo, piuttosto che basarsi su l’IME per visualizzarli.

Enhanced accessibility APIs

Android 4.0 aggiunge nuove caratteristiche di accessibilità e  una enhanced API  per consentire agli sviluppatori di migliorare l’esperienza utente nella proprie applicazioni, in particolare su dispositivi che non dispongono di pulsanti hardware. Per i servizi di accessibilità come gli screen reader, in particolare, la piattaforma offre nuove API per fare query al contenuto nella finestra , per facilitare la navigazione, migliorare il feedback, e interfacce utente più ricche.

• Accessibility API
• Text-to-speech API

Uso Efficente della rete -  network usage

In Android 4.0, gli utenti possono visualizzare la quantità di dati in rete delle loro applicazioni in esecuzione. Essi possono anche impostare i limiti per l’utilizzo dei dati per tipo di rete e disabilitare l’utilizzo dei dati per applicazioni specifiche. In questo contesto, gli sviluppatori devono progettare le loro applicazioni per funzionare in modo efficiente e seguire buone pratiche per la verifica della connessione di rete. Android 4.0 fornisce network API per consentire alle applicazioni raggiungere questi obiettivi.

Come gli utenti passano da reti o limiti stabiliti su dati di rete, la piattaforma permette di interrogare le richieste di tipo di connessione e la disponibilità. Gli sviluppatori possono utilizzare queste informazioni per gestire in modo dinamico le richieste di rete per garantire la migliore esperienza per gli utenti. Gli sviluppatori possono anche costruire una rete su misura e dati di utilizzo delle opzioni nelle loro applicazioni, poi esporle agli utenti direttamente da Impostazioni per mezzo di un nuovo system Intent.

Sicurezza per apps e contenuto

Management delle credenziali

Android 4.0 rende più facile, per le applicazioni, gestire l’autenticazione e le sessioni protette. Un nuovo keychain API e lo storage criptato permette alle applicazioni di memorizzare e recuperare le chiavi private e le loro catene di certificati corrispondenti. Qualsiasi applicazione può utilizzare l’API portachiavi per installare e memorizzare i certificati utente e CA in modo sicuro.

Address Space Layout Randomization

Android 4.0 fornisce ora Address Space Layout Randomization (ASLR) per proteggere applicazioni di sistema e la terza dallo sfruttamento a causa della gestione della memoria.

Miglioramenti per l’Impresa

VPN client API

Gli sviluppatori possono ora creare o estendere le proprie soluzioni sulla piattaforma VPN utilizzando un nuovo VPN API e alla base di memorizzazione sicura delle credenziali. Con il permesso dell’utente, le applicazioni possono configurare gli indirizzi e le regole di routing, il processo di pacchetti in uscita e in entrata, e stabilire tunnel sicuri su un server remoto. Le imprese possono inoltre usufruire di un client VPN standard integrato nella piattaforma che fornisce l’accesso ai protocolli L2TP e IPSec.

Device policy management for camera

La piattaforma aggiunge un nuovo controllo della politica per gli amministratori che gestiscono i dispositivi con un installato Device Policy Manager. Gli amministratori possono ora disabilitare da remoto la fotocamera su un dispositivo gestito per gli utenti che lavorano in ambienti sensibili.

Questo articolo è basato da una libera traduzione dal’Andorid developer Portal (android-4.0-highlights)

• Italiano

Translate original post with Google Translate

Il linguaggio HTML5 avrà un profondo impatto sulla Internet.

Per citare la definizione di Wikipedia, l’HTML5 è un linguaggio di markup per la progettazione delle pagine web attualmente in fase di definizione presso il World Wide Web Consortium.

iOS 5 introduce 1.500 nuove API per gli sviluppatori, compreso l’accesso icloud, Storage, Newstand e Twitter.
Apple ha apportato alcune migliorie sul supporto per html, come Safari Mobile che permette di attingere a maggiori porzioni di memoria locale del dispositivo e ai servizi di geolocalizzazione.

Abbiamo pensato quindi di integrare il supporto all’html5 all’interno del nostro sistema editoriale i3F Editorial.

Vi segnalamiamo a questo proposito un interessante articolo di Bart Termorshuizen autore del Bolg Siteless.Org:
Bart sta lavorando su un piccolo progetto per la creazione di un generico codice basato su HTML5 per la lettura di riviste come soluzione per l’iPad.

L’idea di base è che le soluzioni editoriali adottate dalle corporate sono troppo costose per una vasta gamma di editori. Inoltre, queste soluzioni editoriali non sembrano essere di semplice utilizzo e integrazione e molti non sfruttano la tecnologia HTML5, ma sono derivanti da logiche d’informatizzazione ad alto impatto architetturale.

Crediamo che la semplicità sia la chiave del successo per il mercato delle App online e per questo , come Bart, siamo certi che l’iPad sia un dispositivo meraviglioso per leggere riviste – soprattutto se queste riviste sono ricche di contenuti interattivi.

Creare un app che ti permette di gestire pubblicazioni multiple, con la possibilità di lettura off-line con performance scattanti non è facile.

Se qualcuno volesse cimentarsi con un progetto Xcode puo’ trovare il sources code sul blog http://www.siteless.org/books/SitelessMagazine.zip.

Per una soluzione didattica possiamo provare a dare un’occhiata al framework Baker, Baker framework, Laker compendium and pugpig. Tutto il codice è open source-

Innanzi tutto il codice è:
- siteless magazine è il nome del progetto e prende la grafica e altra roba dal sito Siteless.org a scopo di test
- Minizip per decomprimere
- Json per il parsing json
- pugpig reader (ha delle belle pre-rendering snapshot)

Viewcontrollers:
- LibraryViewController – qui è dove accadono le cose principali. Nota che le copertine fanno riferimento ad una url nella stringa JSON. Oltre alle funzionalità di sincronizzazione (il pulsante in basso a sinistra ), che cura anche la creazione di istanze di oggetti issueviewcontroller e la gestione del layout
- IssueViewController – questo è il viewcontroller di una singola pubblicazione. Il Design (xib) è in bozza. Si occupa anche di scaricare / decomprimere una singola pubblicazione e l’archiviazione (che elimina la pubblicazione dal filesystem)
- ReaderViewController – si prende cura del lettore reale – utilizza il framework pigpug in questa versione open.

il suo modello misto di storage :
- Le pubblicazioni sono memorizzate utilizzando core data (database SQLite). È possibile esaminare il database utilizzando il browser dei database SQLite. Come potete vedere, il database non è incluso – viene creato automaticamente se non esiste.

- Le copertine grafice sono memorizzate sul filesystem – la posizione delle cover sul filesystem viene mantenuta nel database. E’ un path completo – Bart sostiene di un essere incorso in problemi con esso.
- Le Pubblicazioni (dossier) vengono memorizzate sul filesystem. L’operazione ‘archive’ rimuove la pubblicazione mentre ‘download’ la scarica , poi unzippa e inserisce il riferimento ad esso nel database.
Il DataModel è nel file xcdatamodel. La classe Issue, copertina e contenuti sono generati da quel DataModel.

Per verificare che cosa sta succedendo, è facile monitorare la cartella e il database. Ricominciare è anche facile: rimuovere tutto cio’ che si trova in quella cartella (/’user’/Application Support/iPhone Simulator/4.3.2/Applications/’applicationid’/Documents/)

Il formato JSON è facile da capire, assicurarsi che i numeri di serie delle pubblicazioni siano unici. Sul sito di siteless sono incluse due testissue – (pubblicazione numero 1 e 2, da Laker e Pigpug), mentre le altre non esistono.

Qualche necessità per rendere questo codice meno didattico:
- Integrazione del reader. Il reader in questo codice non consente ancora lo scorrimento verticale. Il doppio tap non mostra l’indice. Il pulsante library ha bisogno di essere implemntato. Non aggiornare se si vuole aprire un altra pubblicazione
- Refactoring di alcuni metodi (alcuni sono troppo lunghi e verbosi)
- Generalizzare il codice e includerlo nel github (dopo il test)

• Italiano

Translate original post with Google Translate

L’icona di avvio (launcher icon) è un elemento grafico che rappresenta la nostra applicazione. Le icone di avvio vengono utilizzate per avviare le applicazioni e appaiono sulla schermata iniziale del dispositivo utente.
Le icone di avvio possono essere utilizzate anche per rappresentare i collegamenti (shortcuts) nella vostra applicazione (ad esempio, un’icona di collegamento contatto permette di aprire le informazioni di dettaglio per un contatto).

Quando si disegna per Android è necessario creare le icone separate per tutti i diversi display presenti sul mercato dei device che montano android gli , schermi che hanno diverse densita di pixel potranno essere a bassa, media, alta e altissima densità. Questa differenziazione assicura che le icone verranno visualizzate correttamente in tutta la gamma di dispositivi su cui l’applicazione può essere installata. Vedere Tips for Designers (Suggerimenti per i progettisti) su come lavorare con più set di icone.

Obiettivi del icona di avvio
Esempio di launcher icons per sistemi e applicazioni di terze parti

Esempi di Icone di avvio (laucers icons) per OS Android

Figura 1. Esempi di launcher icons per system applications (sinistra) e applications di terze parti (destra).

Le icone di avvio dell’applicazione hanno tre obiettivi primari:
a. Promuovere il marchio e raccontare la storia delle app.
b. Aiutare gli utenti a scoprire l’applicazione in Android Market.
c. Permettere l’avvio dell’App.

a) Promuovere la storia del marchio
Le icone di avvio applicazione sono l’occasione per presentare il marchio e la storia della vostra applicazione .
Pertanto, si dovrebbe:

• Creare un’icona con uno stile unico e memorabile.
• Utilizzare una combinazione di colori che si adatta il vostro marchio.
• Non cercate di comunicare troppo con l’icona. Una semplice icona avrà più impatto e più memorabile.
• Evitare di includere il nome dell’applicazione nell’icona. Il nome della applicazione sarà sempre visualizzato accanto all’icona.

b) Aiutare gli utenti a scoprire l’applicazione in Android Market
Le icone di avvio fornicono una prima impressione agli utenti potenziali in Android Market. Un icona di alta qualità può influenzare gli utenti che scorrono gli elenchi di applicazioni.

Un icona ben progettata può essere un segnale forte che la vostra applicazione sarà di qualità altrettanto elevata. Consideriamo quindi di lavorare con un designer professionista per sviluppare un’icona di avvio per la nostra applicazione.

c) Funzionare e pemettere l’avvio
Un’icona di successo dovra’ essere ben definita in tutte le situazioni: su qualsiasi sfondo e accanto ad altre icone e widget app.

Per fare questo, le icone dovrebbero:

• Comunicare bene anche dimensioni ridotte.
• Lavorare con una vasta gamma di sfondi.
• Rispecchiare il tipo di illuminazione del laucher (top-lit).
• Se l’icona è 3D, utilizzare una prospettiva che non sia fuori luogo con le altre icone, forward-facing (rivolte in avanti) funziona meglio.
• Icone 3D funzionano meglio con una ridotta profondità.
• Avere un profilo unico per rendere veloce il riconoscimento, non tutte le icone Android app devono avere dimesioni quadrate.
• Le icone non dovrebbero presentare un quadro ritagliato di un’immagine più grande.
• Avere un peso simile ad altre icone. Le icone che sono troppo sottili o che non utilizzano abbastanza spazio spesso non attirano l’attenzione dell’utente, o possono non stare bene in tutti i contesti/background.

Dimensioni e formato
Le icone di avvio dovrebbero essere a 32-bit PNG con un canale alfa per la trasparenza. Le dimensioni finali un’icona di avvio corrispondente a una data densità dello schermo sono riportate nella tabella sottostante.

Table 1. Summary of finished launcher icon dimensions for each generalized screen density.
Tabella 1. Sommario delle dimensioni dell’icona per ogni densità schermo.

È anche possibile includere pochi pixel di padding (imbottitura) nell icone di avvio per mantenere un peso costante visivo con le icone adiacenti. Ad esempio, un’icona di avvio a 96 x 96 pixel xhdpi può contenere una forma 88x 88 pixel con 4 pixel su ogni lato per padding. Questa imbottitura o padding può essere utilizzata anche per fare spazio a un’ombra sottile, che può aiutare a garantire che le icone di avvio siano leggibili in tutto su qualsiasi colore di sfondo.
Icone delle applicazioni in Android Market
Se si pubblica l’applicazione su Android Market, è necessario fornire anche un icona artwork di 512 x 512 pixel ad alta risoluzione. Questa icona sarà utilizzata in Android Market e non sostituisce l’icona di avvio.

Per suggerimenti e raccomandazioni sulla creazione di icone ad alta risoluzione di avvio che può essere facilmente scalata fino a 512×512, si possono vedere Suggerimenti per Designer sul sito Android Developer (Tips for Designers).

Per informazioni e specifiche sulle icone ad alta risoluzione per l’applicazione in Android Market, vedere anche il seguente articolo:
Graphic Assets for your Application (Guida di Android Market)

Cosa fare e cosa non fare
Di seguito sono riportati alcuni esempi presi dalla guida Android developers su come “fare e non fare” , sono esempi da prendere in considerazione quando si creano le icone per l’applicazione.

Disegno Troppo complicato ? Semplificare le icone non dovrebbe essere eccessivamente complicato. Ricorda che le icone di avvio saranno utilizzate a dimensioni spesso piccole, quindi dovrebbero essere distinguibili a dimensioni ridotte.

Icona ritagliata e opaca (cropped and glossy) ? Le icone non devono essere tagliate. Utilizzare forme uniche, se del caso, ricordate che le icone di avvio dovrebbe differenziare la vostra applicazione. Inoltre, non usare troppo lucido (glossy) a meno che l’oggetto rappresentato è un materiale lucido.

Troppo sottile? Le icone non devono essere sottili. Dovrebbero avere un peso simile a quello altre icone. Le icone troppo sottili non si distinguono bene con tutti i background.

Full-frame oppure sottilmente arrotondati e trattati ?Le icone dovrebbero utilizzare il canale alfa, e non dovrebbe essere semplicemente delle immagini full-frame. Distinguere , quando possibile, la propria icona con un lieve ma accattivante trattamento visivo.

fonte: libera traduzione dalle Android Guidelines

• Italiano

Translate original post with Google Translate

Pasticcini alle icone di iOS

Le icone e le immagini sono una parte fondamentale l’esperienza degli utenti iOS.
Lungi dall’essere un’elemento puramente decorativo, le icone e le immagini nelle nostre applicazioni svolgono un ruolo essenziale nel comunicare con gli utenti.

Per ottenere i migliori risultati, possiamo arruolare un grafico professionista. Un progettista ed esperto grafico può aiutare a sviluppare uno stile visivo integrato per la vostra applicazione e applicare tale stile a tutte le icone e le immagini del caso.

Apple consiglia di utilizzare le immagini in stile universale in modo che la gente possa facilmente riconoscerle. Eviteremo quindi di concentrarsi su  aspetti secondari o poco visibili.

I tecnici Apple abbracciano la semplicità. In particolare, di consiglia di evitare di stipare un sacco di immagini diverse nella vostra icona. Provate a utilizzare un singolo oggetto che esprime l’essenza della vostra applicazione. Si inizia con una forma di base per poi aggiungere i dettagli con cautela. Se il contenuto di un’icona o la forma è eccessivamente complesso, i dettagli possono diventare confusi e può sembrare sfocato quando ridotto in piccole dimensioni.

L’ utilizzo dei colori e ombre leggere possono aiutare l’icona a esprimere meglio il suo ruolo. Non aggiungeremo quindi il colore solo per fare l’icona più colorata. Inoltre, graduienti regolari di solito funzionano meglio della colore diffusion

In generale, bisogna evitare di utilizzare il testo “greco” o linee ondulate per sottolineare il testo. Se si desidera visualizzare del testo nell’icona, ma non volete attirare l’attenzione sulle parole stesse, iniziare con un testo  poi renderlo piu’ leggibile con lo shirnk e/o raddoppiando i layer .

In generale, creare una versione stilizzata del soggetto piuttosto che utilizzare una foto, anche se a volte può essere opportuno utilizzare una foto (o uno screenshot) per un icona.

Se la vostra applicazione ha un’interfaccia utente molto riconoscibile, è consigliabile creare una rappresentazione di essa invece di utilizzare un immagine del software nell’icona dell’applicazione. La creazione di una versione migliorata dell’interfaccia utente è particolarmente importante in quanto gli utenti potrebbero confondere una versione più grande dell’icona con l’interfaccia stessa del app.

Evitare di utilizzare elementi di interfaccia iOS nel disegno. Non si vuole che gli utenti possano confondere le icone o immagini con l’interfaccia utente iOS.

Non usare le repliche di prodotti hardware di Apple nel disegno. I simboli che rappresentano i prodotti Apple sono protetti da copyright e non possono essere riprodotti in icone o immagini. In generale, è una buona idea per evitare repliche di tutti i dispositivi specifici nel disegno, perché questi disegni cambiano di frequente e le icone o immagini che si basano su di esse può apparire datato.

Non riutilizzare iOS icone delle applicazioni nella vostra interfaccia. Può essere fonte di confusione per gli utenti di vedere la stessa icona utilizzata per indicare cose leggermente diverse in luoghi diversi in tutto il sistema.

Ritrarre sostanze reali con precisione. Le icone che rappresentano gli oggetti reali dovrebbero apparire come se fossero fatti di materiali reali e con massa reale. Icone realistiche replicano con precisione le caratteristiche delle sostanze come tessuto, vetro, carta e metallo, e dovranno trasmettere l’idea del peso di un oggetto.

Utilizzare la trasparenza solo quando ha senso. La Trasparenza in un’immagine può aiutare a descrivere materiali come il vetro o la plastica, ma può essere complicato da usare in maniera convincente. Si consiglia quindi di non utilizzare la trasparenza nella vostra icona dell’applicazione.