Categories
Non classé

Quelques nouvelles

Voilà fort longtemps que je n’ai rien écrit sur ce blog. Ces derniers mois en fait furent très occupés.

Tout d’abord, je donne dorénavant des formations au développement sous iOS pour le compte de la société Mediabox. Tout se passe bien: les gens de Mediabox sont sympas, les locaux sont nickels et en plus, on mange bien à midi au bistrot du coin. Les premiers stagiaires que j’ai eu étaient motivés et nous sommes allés quasiment au bout du programme de la formation, finalement très chargée (surtout après le repas au bistrot, si on a pris une entrée). Si ça vous intéresse, la prochaine session est déjà programmée du 24 au 28 octobre.

J’ai travaillé sur la version iPad de PortraiMatic; non le projet n’est pas abandonné, en fait, le logiciel tourne déjà plutôt correctement, il me reste un travail d’optimisation (mémoire et vitesse) et de finition avant de le proposer à mes bêtas testeurs en vacances.

En parlant de vacances, les miennes sont terminées. Peupeul a eu l’idée de lâcher son nouveau félin “Lion” (Mac OS 10.7) pile au milieu de mon séjour, si bien que je le découvre seulement aujourd’hui. Et évidemment, PortraiMatic est incompatible, alors que la transition de 10.5 à 10.6 s’était faite sans douleur. (D’accord, j’admets que c’est de ma faute, parce que je n’ai pas pris le temps de tester les bêtas de Lion, mais quand même, je me demande ce qu’ils ont changé pour que ça foire autant).

Pour finir, je re-découvre Twitter. Vous pouvez dorénavant suivre mes aventures sous @renaudpradenc.

Categories
Non classé

PortraiMatic iPad (2): Reprendre le code de la version Mac ?

C’est décidé, je vais convertir PortraiMatic du Mac à l’iPad. Mais par où commencer ?

Faut-il reprendre le code de la version Mac ?

Il s’agit d’une question économique, à savoir: sachant que les bibliothèques de développement Mac et iOS possèdent de nombreuses similitudes, peut-on partager les fichiers sources entre les deux plateformes ? Après tout, le langage de programmation est le même, et Cocoa Touch est une adaptation de Cocoa Mac. Et si la réponse est positive, est-ce que la lourdeur structurelle (mise en place sous Xcode) n’anéantis pas le bénéfice de cette réutilisation?

Le gros du code concerne l’IHM

L’Interface Homme-Machine représente une grosse proportion dans PortraiMatic. Or, il s’agit probablement d’une des plus grosses différences entre Mac OS et iOS. D’un côté, nous utilisons App Kit, de l’autre UIKit. Il ne s’agit pas d’une simple adaptation: les ingés d’Apple l’ont repensé pour l’utilisation avec un écran tactile et l’ont grandement modernisé.

PM_ReframeView

Par exemple, je sais d’avance que je vais devoir reprogrammer entièrement la vue qui sert à recadrer les portraits. Or, il s’agit de la classe la plus complexe de PortraiMatic Mac.

Pas de bindings

Les Bindings sont une des technologies les plus utiles, mais également les plus complexes qui existe sur Cocoa Mac. Cette technologie synchronise l’état des vues (ce qui apparaît à l’écran) et l’état interne (couche ‘métier’). PortraiMatic en fait grand usage, entre autres parce qu’elle réduit les dépendances entre classes, et donc la complexité de l’architecture. Pour des raisons de performances, je pense, cette technologie n’a pas (encore) trouvé son chemin dans Cocoa Touch. Il existe des alternatives, mais cela signifie à nouveau que de grand pans du code ne peuvent pas être réutilisés.

Pas de Core Image

Core Image est ma technologie préférée dans Mac OS X. Elle permet d’appliquer des effets sur les images voire de générer des images. C’est une technologie à la fois performante, facile à utiliser et extensible. Malheureusement, elle n’a pas encore été portée sous iOS, même si je ne doute pas que cela sera fait prochainement. En conséquence, j’ai décidé, dans un premier temps, de ne pas inclure de fonctions de corrections de couleurs dans la version iPad. Non, pas que ceci me poserait de problème particulier (la programmation graphique est ma spécialité), mais je veux publier l’application rapidement.

Gestion des fichiers

La gestion des fichiers dans PortraiMatic est à la fois un motif de satisfaction — parce qu’elle est maintenant bien au point — et une inquiétude à chaque nouvelle version pour s’assurer de la compatibilité avec les versions précédentes. Elle présente quelques détails malins. Tout d’abord, la “galerie” est un bundle, c’est à dire un dossier qui apparaît comme un fichier sous Finder. On peut l’ouvrir sous Finder, par un clic droit > Afficher le contenu du paquet, et constater que chaque portrait possède son dossier:

PM_BundleGalerie

Chaque dossier comporte l’image utilisée par le portrait et un fichier Portrait.plist qui décrit les paramètres du portrait (recadrage, correction des couleurs). Cette organisation s’est révélée pratique en cas de problème (on peut mettre un dossier à la corbeille), plus simple à déboguer (on voit immédiatement si les données ont été enregistrées). Elle a aussi permis de mettre en œuvre facilement la fusion des galeries de deux utilisateurs. Cependant, je vais passer à Core Data pour enregistrer les données.

Core Data permet de décrire le modèle (la partie “métier”) de l’application de façon graphique et de stocker les informations dans une base de données SQLite de façon transparente. J’en attends des simplifications de l’architecture et une baisse de volume du code source. Par ailleurs, elle devrait régler mes soucis de migration d’une version à l’autre, en m’obligeant à décrire précisément les évolutions de chaque version.

À l’heure du choix

Finalement, je constate que peu de code peut être repris; si nécessaire, je dispose toujours de la possibilité de copier-coller du code. Je n’ai franchement pas envie de m’engager dans des problèmes d’inclusions de fichier d’un projet Xcode à l’autre. Il me semble donc plus opportun de ne pas partager de fichiers entre les versions Mac et iPad, et de créer un projet Xcode tout neuf.

Categories
Non classé

PortraiMatic iPad (1): Objectif du projet

Je me suis décidé à convertir mon logiciel PortraiMatic du Mac à l’iPad. Je débute donc une série d’articles qui vous permettra de suivre l’avancement de l’application, mais surtout qui vous expliquera mes choix et les problèmes que j’ai rencontré.

L’objectif du projet

Quand développer un logiciel est un loisir, il importe finalement peu que ce projet ait un avenir; on le fait avant tout pour le plaisir, pour le challenge intellectuel. À l’inverse, dans le cadre d’une société, chaque choix doit être motivé. Aussi doit on avoir des objectifs avant d’investir son temps dans l’écriture d’une application. L’objectif le plus courant est de gagner de l’argent, mais peut être de se former, de tester la faisabilité technique d’une idée, ou de promouvoir la société.

Version iPhone

On m’a demandé à de nombreuses reprises pourquoi PortraiMatic n’existait pas sur iPhone. La réponse est très simple: ce serait un mauvais investissement. Il existe déjà un palanquée d’application à 0,79 € pour produire des planches de photos d’identité. Même si je concevais le meilleur programme du genre — ce qui est probable — elle ne pourrait guère être vendue plus d’1,59 €. Rappelons que sur 1,59 €, la société ne toucherait que (1,59 – 15% de TVA – 30% de commission d’Apple) = 0,95 €. Rappelons que pour me verser un salaire de 1500 € nets/mois, cela coûterait à la société Céroce à peu près le double pour payer les charges sociales, soit 3000 €. Rappelons que les sociétés sont soumises à divers impôts et ont des frais, ne serait-ce qu’un loyer, des abonnements au téléphone et à Internet, d’importants frais de transport, acheter des Mac ou iPad ou une imprimante, et toutes les fournitures qui vont avec, de la documentation, un comptable, etc. Eh bien on arrive vite à 5000 €/mois. Notez que je ne fais pas cet inventaire pour me plaindre de “toutes ces charges qui plombent les entreprises”, comme on dit au MEDEF, mais pour effectuer un calcul réaliste.

Imaginons que je passe trois semaines sur le développement de la version iPhone (ce qui est optimiste), il faudrait qu’elle rapporte 3/4 de 5 000 € soit 3 750 €. Le premier jet serait donc rentable avec 3 948 ventes. Or, si vous croyez que c’est facilement atteignable, vous vous trompez lourdement. L’application serait noyée au milieu de 350 000 autres ! Si bien qu’il faudrait un plan marketing pour y parvenir, qui prend du temps et a un coût. C’est bien simple, si la promotion prenait trois semaines, il faudrait vendre deux fois plus d’exemplaires. Bref, j’ai préféré ne pas investir mon précieux temps sur ce marché.

Version iPad

Pourquoi une version iPad alors ? Certes la concurrence y est moindre (seulement 65 000 applications) et je pourrais pratiquer un prix de vente plus correct, autour de 5 €. Mais à vrai dire, je doute fortement que le coût du développement sera couvert par les ventes. L’objectif est ailleurs: démontrer mon savoir faire sur cette plateforme. Comme tout prestataire amené à démarcher des clients, il me faut les convaincre de ma capacité à réaliser un projet complexe. Cette version iPad sera mon ambassadrice. Quand l’iPad fut présenté l’année dernière, je me suis dit que c’était la machine idéale pour PortraiMatic. C’est encore plus vrai pour l’iPad 2 et ses caméras intégrées.

Categories
Non classé

Cong

Stéphane Sudre vient de publier un nouveau logiciel du nom de Cong. Ce logiciel fait écho à sa présentation de novembre à Cocoa Heads Paris, où il nous parlait d’un contrôle qualité artisanal d’une application. Je me rappelle lui avoir dit que ces contrôles prenaient trop de temps pour que je les fasse à chaque version de l’application… Cong est la solution.

Pour comprendre à quoi sert ce logiciel, analysons une application; par exemple PortraiMatic:

CongPortraiMatic

Cong recherche les anomalies dans les ressources de l’application. Elles sont ensuite classées dans trois catégories: erreur, avertissements et remarques.

Pour PortraiMatic, sont ainsi signalées des erreurs de typographie, des erreurs sur la clé CFBundleTypeExtensions d’Info.plist, et d’autres erreurs liées à Sparkle. Il ne me reste plus qu’à les corriger pour une prochaine version.

Categories
Non classé

Mac App Store

Si vous lisez ce blog, vous savez sans doute qu’Apple a annoncé mardi la disponibilité prochaine d’un Mac App Store, qui permettra d’acheter, de télécharger et d’installer automatiquement les logiciels sur son Mac. J’ai l’intention de rendre PortraiMatic disponible par ce canal (qui — ne nous méprenons pas — va vite devenir incontournable), mais qui n’est pas sans poser de questions.

Ma première question est la part qu’Apple prélèvera sur les transactions. La boutique équivalente pour iOS prélève 30% de commission: c’est élevé, comparé à mon système de paiement actuel, basé sur Kagi, qui prélève environ 15% (et qui est déjà cher). Je serais obligé d’augmenter le prix du logiciel, ma marge étant déjà peu élevée.

Ma seconde question est si le magasin, à l’instar de son homologue sous iOS, permettra les achats ”in-app” (à l’intérieur de l’application). Ceci pourrait ouvrir de nouvelles perspectives commerciales.

Ma dernière question, qui n’en est pas une, est qu’il faudrait que je maintienne deux versions:

  • la version pour l’App Store
  • la version actuelle avec son écran d’accueil pour prévenir que le logiciel n’est pas enregistré, et son débridage par code.

ou alors, si je pouvais faire toutes mes ventes par l’App Store:

  • la version pour l’App Store
  • une version de démonstration

Cette deuxième solution offre l’avantage de la simplicité, mais pose un autre problème: PortraiMatic est compatible avec Mac OS 10.5. Devrais-je abandonner cette compatibilité ? Nous devrions y voir plus clair lors du lancement de la boutique en décembre.