• 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

Guide Turistiche e Directory per iPhone, iPad & Android

• Italiano

Translate original post with Google Translate

iOS 5 Tech Talk World Tour, Rome 9-11-2011

i3Factory ha partecipato all’evento organizzato da Apple a Roma, iOs Tech Talk World Tour 2011 .

Senza badare a spese Apple inc. ha organizzato un evento gratuito dedicato a tutti gli sviluppatori e a cui hanno partecipato diversi esperti che provenivano dalle sedi Apple del mondo.
L’evento era a numero chiuso e ne sono stati preselezionati i partecipanti.

L’evento iOS 5 Tech Talk World Tour si e’ tenuto il 9 novembre 2011 al Marriott Park Hotel di Roma; Appena arrivati ci siamo registrati alla velocita’ della luce (intelligentemente hanno trovato il modo di non farti fare noiose file per ottenere il badge) , quindi diretti nella sala “Michelangelo” inziavamo a riconoscerele persone dello staff Apple. Senza troppi convenevoli si poteva far colazione liberamente con il tipico caffé americano e connettersi alla rete Wi-Fi gratuitamente offerta.

Di seguito la galleria foto:

iOS 5 Tech Talk World Tour, Rome 9-11-2011

• Italiano

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.

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.

Block 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.

• Italiano

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.

• Italiano

Dear Editors,

finally we made a system that allows you to publish magazines, books, newspapers,catalogs or any publication at no cost to each new issue or for every new player.

We cater to small publisher as the major publishing house, after having tested our prototypes, and after more than one year of development, i3Factory® is pleased to introduce a software system that allows you to publish your own issues without expensive investments on the App Store .

Through Apple’s App Store, Android Market or Amazon App Store,  your audience market will become the world’s online market, then the possibility of reaching readers around the world.

The costs of printing paper are more and more high and not allow the publisher of large print runs, and then plan to reach a geographically more wide.

With our publishing system, the costs of printing are canceled; readers browse your publication on the iPad tablet (and iPhone) and the cost for new publications will be always null.

We note that the experience of reading a magazine on the iPad and far more satisfactory experience of reading the same publication on paper.

SOME FEATURES

1. Your Own Universal Application will be published on Apple® App Store;
   
2. Unlimited publications from PDF files;
3. No infrastructures costs: Host the publications on your own Internet or Intranet servers. Have 100% control and autonomy on your content;
4. Offer your readers & audience the best mobile/tablet browsing experience with high definition texts and images, Videos and so much more;
5. Wide audience: you pubblications will be ready Wold Wide;

Magazine using i3Factory editorial

ADVANTAGES

• Economy of Scale: Buy one time license and create as many mobile publications as you wish in a just few clicks!
• Earnings:Editors can offer prublication for free or not free.

• Easy-to-use: Easily publish your magazione or publications from your  PDFs. i3Factory Editorial® technology automatically exports your links and your bookmarks from your PDF to your iPad & iPhone App.

• Mobility: Consult your  publications offline , once downloaded the publication will be avaiable for  read it without you need any tipe of online connections.

• Fast Download: all operation works on wifi or 3G data connections, Give your audience a great experience; with an internet connection the pages are immediately available as you flip through the document.

• Sustainable Development: Go green. With i3Factory Editorial® all your publications have a positive carbon balance sheet. Help preserve our environment, save paper, reduce printing, save the trees and help decrease green house gases!

• Personalization: Create your “Own Graphic interface” for your readers and a table of content for quick navigation.

• Security: Host your publications on your own Internet or Intranet servers. Stay in full control of your interactive publications and your content (archives, subscription, sales campaign …).

• Multimedia Content: Add clickable zones (go to page or links to websites) inside your interactive publication and/or PDF , HTML5. Engage readers withInteractivity & Videos from inside the pages of your publication.

• Performance: You can find what you want in the blink of an eye.

• Technology: i3Factory is a certified Application Factory. We are up to date with the latest technological developments, hence allowing us to provide you with the most high-performing tool on the market today.
  
  Be on the cutting edge of technology!

COSTS

Obviously prices will vary with respect to the need of the publisher, which normally requires some “customization”.

The starting price for our solution starts from 900 euros for small publishers, a solution that contains all the features necessary for most small-medium-sized publishers that starts from 1500 euros up to a maximum of € 5000 for medium and big publishers.

More Information on packages you can find on this editorial on this page:

New editorial system for iPad, iPhone & Android

or  direct on  i3F Editorial web site (http://i3factory.com/editorial)

• Italiano

Translate original post with Google Translate

Steve Jobs al D8 2010 parla di Adobe Flash

Nel corso del D8, conferenza organizzata da All Things Digital, Blog del Wall Street Journal, il CEO Apple Steve Jobs (iCEO) ha rilasciato un’interessante intervista, in cui ha parlato della ormai annosa questione di Adobe Flash, della competizione con Google, di Foxconn e il futuro della TV.

Per quanto riguarda Flash, Steve racconta che non aveva in mente di iniziare una guerra con Adobe, ma voleva di operare  una scelta  strettamente tecnica:

Talvolta, quando ci sbarazziamo delle cose, la gente ci chiama pazzi. Ma qualche volta è meglio tenersi solo i cavalli migliori, quelli proiettati in avanti.  Flash ha avuto il suo momento di gloria, ma è HTML5 che sta emergendo. Il video è migliore e funziona meglio, e non si ha bisogno di un plugin per vederlo. Cerchiamo solo di fare prodotti grandiosi.

Considerando che attualmnete Apple sta vendendo un iPad ogni 3 secondi, e’ facile pensare che il mercato gli  sta dando ragione. Molto interessante anche il punto di vista su Foxconn, il piu’ grande produttore Cinese di tecnologia (wiki) e la serie di suicidi che sono avvenuti negli ultimi mesi:

Foxconn non sfrutta i propri dipendenti. Hanno ristoranti e piscine. Per essere una fabbrica, è una fabbrica molto bella. Abbiamo inviato i nostri e qualche  esterno per dare un’occhiata più da vicino alla faccenda.

Riguardo al rapport con Google le cose non sembrano sul punto di cambiare, almeno nel breve periodo. La rivalità  tra le due società non è un segreto ma Jobs nega la possibilità che il motore di ricerca Google venga sostituito coi prodotti della concorrenza (il velato accenno è a Bing) .

Su iPad e il futuro dei netbook, Steve accenna una metafora è di tipo storico-automobilistico:

Quando eravamo una nazione prevalentemente agricola, tutte le automobili erano simili a furgoni. Ma a mano a mano che la gente si spostava verso i centri urbani, hanno iniziato a diventare le automobili che conosciamo. Ritengo che i PC stiano per assomigliare ai furgoni. Sempre meno gente ne avrà bisogno, e questo metterà a disagio qualcuno.

La questione è quindi di tipo culturale, più che tecnologico, le potenzialità praticamente illimitate dell’iPAd e le possibilità sono ancora largamente inesplorate:

La trasformazione dei PC a nuovi form factor come il tablet rischia di rendere qualcuno nervoso perché il PC è stato con noi per parecchio tempo. Il PC è brillante, e amiamo parlare dell’era post-PC, anche se un po’ ci mette a disagio. Perché non sarebbero adatti alla creazione dei contenuti? Non può essere colpa della potenza del software, anche perché è in continua evoluzione. Questi dispositivi nel tempo cresceranno per fare nuove cose come app di produttività o editing video.

Link all’intervista

http://video.allthingsd.com/video/d8-steve-jobs-on-foxconn/43D148EF-4ABF-402D-B149-8681DF01981A

• Italiano

Translate original post with Google Translate

Benvenuto nella i3Factory … la tua fabbrica di applicazioni per iPhone!

Il mondo sta cambiando verso una crescente socializzazione e mobilitazione di contenuti e applicazioni.

Oggi, con la nascita di i3Factory, potete finalmente contare su una rete di specialisti e ingegneri altamente flessibile e distribuita che permettera’ di lanciare idee per applicazioni iPhone, Ipod, Ipad.
Le vostre idee saranno sul mercato online in pochissimo tempo. Un questione di giorni, non mesi!

Inoltre i3factory ® fucina attiva di idee, che noi stessi creiamo, progettiamo, sviluppiamo e lanciamo in Apple App Store ®.

Quindi, se sei un individuo o una societa’ e se hai un’idea che vorresti vedere pronta,la fuori, in tempi rapidi e posizionarla al piu’ presto sul mercato mettiti in contatto con i3Factory!

Non ci piace perdere tempo, la nostra soddisfazione arriva solo nel momento in cui la tua idea sara’ disponibile e pubblicata worldwide sull’App Store® .

Se ti piace il modo con cui affrontiamo i progetti, le idee e la velocita’ con cui sviluppiamo le applicazioni per iPhone, Ipod e Ipad possiamo sicuramente trovare un punto di discussione.

Chi siamo

Quindi non esitare, contattaci all’indirizzo:
info(a)i3factory.com

• Italiano

Translate original post with Google Translate

Steve Jobs and ipa

Le dimensioni dell’iPad: 680 grammi per 1,27 centimetri. Uno schermo multi-touch da 9,7 pollici

Si accede all’ App store¬† oggi 140mila applicazioni sono compatibili con iPad.

Wifi, 3G opzionale

• Italiano

Translate original post with Google Translate