Aller au contenu


Photo

Quels outils?


  • Please log in to reply
7 replies to this topic

#1 Zbooby17

Zbooby17

    Membre

  • Membres
  • Pip
  • 5 Messages :

Posté 02 avril 2007 - 15:07

Je sais que la question a déjà été rabattue mais ne trouvant pas vraiment de réponse précise je me permets de poser cette question pour essayer d'en faire une synthèse.
En fait, je viens de switcher et je souhaiterais m'initier au développement d'applications sous Mac OS-X.
Je ne suis pas débutant en programmation. J'ai un peu touché à tous les langages et j'ai déjà géré des sgbd.
Je souhaiterais développer une appli de type 'bibliothèque' (de n'importe quoi: cd, timbres, etc.) et j'aimerais savoir ce qui est le plus approprié. Sous Windows j'aurais choisi WinDev qui intègre tout ce qu'il faut mais un tel AGL n'existe pas sous Mac. Non?
Quel ensemble me suggérez vous donc: environnement de développement, langage, interface homme-machine, SGBD, déploiement (package) qui vous semblerait le plus efficace pour faire une appli s'intégrant bien dans l'OS.
Merci

#2 odr

odr

    Maniaque du clavier

  • Membres
  • PipPipPipPip
  • 521 Messages :
  • Configuration:Apple II
  • Sexe:Masculin

Posté 02 avril 2007 - 17:45

A mon avis :
xCode (env) Objective C (lang) Interface Builder (ihm), XML (bd)
Niveau IHM qui s'intègre bien dans l'os, interface builder (fournit avec xcode) c'est l'interface aqua.
Objective-C en langage pour avoir tous les services facilement.
XML comme base de donnée. XML est déjà utilisé pour le prefs de mac os par ex, ça évite d'avoir un vrai SGBD d'installé.

Xcode se télécharge gratuitement sur le site dev d'apple
Il vaut mieux prendre chaud en mangeant que froid en travaillant - Sagesse lyonnaise

#3 AliGator

AliGator

    (Trop) Grand Bavard

  • Membres d'honneur
  • PipPipPipPipPipPipPipPipPip
  • 12 338 Messages :
  • Configuration:• MacBook Pro 15" 2,2GHz, 10.6
    • MacMini G4 1,42GHz, 10.5
  • Sexe:Masculin
  • Localisation:Rennes (Bretagne, France)
  • Passions:Piano, Cuisine, Danse (Rock, ...), faire des rĂ©ponses de 3km

Posté 02 avril 2007 - 20:46

Hello et bienvenue, sur Mac comme sur macfr.com !

Alors en effet il y a plusieurs solutions, cela dépend de ce que tu veux faire mais aussi de ton niveau en développement.

1) Si tu veux développer ça au sens "programmeur" du terme, donc te faire plaisir avec des lignes de code parce que c'est ton dada, alors Objective-C (langage), Cocoa (framework), xCode (IDE) et InterfaceBuilder (builder d'IHM et data bindings) sont les outils qu'il te faut. D'autant qu'ils sont gratuits et livrés sur le DVD d'installation de ton Mac, et aussi téléchargeable sur l'ADC (developer.apple.com, inscription gratuite).

Pour la gestion des données, il y a plusieurs solutions :
- soit tu sauves tes données au format XML comme te le propose ODR,
- soit tu fait une sérialisation (il y a tout ce qu'il faut dans Cocoa avec les NSArchiver et NSUnarchiver par exemple, c'est assez facile de stocker des données dans un fichier),
- soit tu utilises véritablement un système de base de données, le plus approprié si c'est pour une utilisation monoposte étant un truc comme sqlite (dont tu as certainement déjà entendu parler ?), avec qui tu pourras t'interfacer en programmant en Objective-C sans problème.

Pour info l'Objective-C n'est qu'une surcouche du C qui rajoute des concepts objets. Si tu as déjà des notions de C ou C++ ainsi que des notions de POO, ça devrait t'aider.

2) Si tu veux juste mettre au point des base de données, mais sans vouloir trop taper dans les lignes de code, il te faut un logiciel de bases de données, comme FileMaker par exemple (le plus connu parmi les "abordables" en terme de prix ;)). C'est spécialisé dans les bases de données, tu fais tes tables, tes modèles/tes états, tes scripts si besoin, etc... et pas de ligne de code (juste un peu de script si tu en as besoin, et encore c'est du drag&drop d'instructions)

3) Dernière solution, tu attends encore quelques mois (j'espère bien d'ici la fin de l'été, mais je vais pas m'avancer c'est pas moi qui développe le soft) et un de mes amis devrait sortir un soft assez complet orienté gestion de données et développement d'applications... mais je vais rien dire de plus ni m'avancer plus, je le laisserai en parler lui-même quand il le jugera utile)

Le posteur fou de macfr
Mon blog: Crunchy Development
______________
Devise Shadok : S'il n'y a pas de solution, c'est qu'il n'y a pas de problème...


#4 Zbooby17

Zbooby17

    Membre

  • Membres
  • Pip
  • 5 Messages :

Posté 02 avril 2007 - 22:01

Merci pour ta réponse dont je vais examiner les différentes option. C'est vrai que je peux dans un premier temps faire quelque chose sans trop de code. Ensuite je pourrai me faire plaisir...

Hello et bienvenue, sur Mac comme sur macfr.com !

Alors en effet il y a plusieurs solutions, cela dépend de ce que tu veux faire mais aussi de ton niveau en développement.

1) Si tu veux développer ça au sens "programmeur" du terme, donc te faire plaisir avec des lignes de code parce que c'est ton dada, alors Objective-C (langage), Cocoa (framework), xCode (IDE) et InterfaceBuilder (builder d'IHM et data bindings) sont les outils qu'il te faut. D'autant qu'ils sont gratuits et livrés sur le DVD d'installation de ton Mac, et aussi téléchargeable sur l'ADC (developer.apple.com, inscription gratuite).

Pour la gestion des données, il y a plusieurs solutions :
- soit tu sauves tes données au format XML comme te le propose ODR,
- soit tu fait une sérialisation (il y a tout ce qu'il faut dans Cocoa avec les NSArchiver et NSUnarchiver par exemple, c'est assez facile de stocker des données dans un fichier),
- soit tu utilises véritablement un système de base de données, le plus approprié si c'est pour une utilisation monoposte étant un truc comme sqlite (dont tu as certainement déjà entendu parler ?), avec qui tu pourras t'interfacer en programmant en Objective-C sans problème.

Pour info l'Objective-C n'est qu'une surcouche du C qui rajoute des concepts objets. Si tu as déjà des notions de C ou C++ ainsi que des notions de POO, ça devrait t'aider.

2) Si tu veux juste mettre au point des base de données, mais sans vouloir trop taper dans les lignes de code, il te faut un logiciel de bases de données, comme FileMaker par exemple (le plus connu parmi les "abordables" en terme de prix ;)). C'est spécialisé dans les bases de données, tu fais tes tables, tes modèles/tes états, tes scripts si besoin, etc... et pas de ligne de code (juste un peu de script si tu en as besoin, et encore c'est du drag&drop d'instructions)

3) Dernière solution, tu attends encore quelques mois (j'espère bien d'ici la fin de l'été, mais je vais pas m'avancer c'est pas moi qui développe le soft) et un de mes amis devrait sortir un soft assez complet orienté gestion de données et développement d'applications... mais je vais rien dire de plus ni m'avancer plus, je le laisserai en parler lui-même quand il le jugera utile)



Je n'avais pas pensé à XML. Merci pour l'idée.

A mon avis :
xCode (env) Objective C (lang) Interface Builder (ihm), XML (bd)
Niveau IHM qui s'intègre bien dans l'os, interface builder (fournit avec xcode) c'est l'interface aqua.
Objective-C en langage pour avoir tous les services facilement.
XML comme base de donnée. XML est déjà utilisé pour le prefs de mac os par ex, ça évite d'avoir un vrai SGBD d'installé.

Xcode se télécharge gratuitement sur le site dev d'apple



#5 AliGator

AliGator

    (Trop) Grand Bavard

  • Membres d'honneur
  • PipPipPipPipPipPipPipPipPip
  • 12 338 Messages :
  • Configuration:• MacBook Pro 15" 2,2GHz, 10.6
    • MacMini G4 1,42GHz, 10.5
  • Sexe:Masculin
  • Localisation:Rennes (Bretagne, France)
  • Passions:Piano, Cuisine, Danse (Rock, ...), faire des rĂ©ponses de 3km

Posté 02 avril 2007 - 22:51

Rebonsoir,

Alors il y a une solution que j'ai (volontairement) omis dans mon premier post, c'est CoreData (et les bindings que j'ai un peu évoqué).

En effet en programmant avec Xcode et InerfaceBuilder (gratuits et dispos sur le DVD fourni avec ton mac) tu peux faire des lignes de code (il faudra te mettre à l'Objective-C, langage un peu déroutant au début mais bon) pour piloter ton interface, mais il y a aussi plein de petites choses pour lesquelles tu peux te passer de lignes de code.

1) Les bindings : ils te permettent de te passer de morceaux de "glue code" comme par exemple quand on change la sélection d'une liste, mettre à jour automatiquement tous les champs qui contenaient les informations sur la ligne sélectionnée. Ou encore changer la dispobinilité ou la visibilité d'un objet suivant la valeur d'un champ (bouton OK désactivé tant que le champ est vide), etc. Plein de petits automatismes facilitant la vie de ce côté.
Ca n'empêche pas de faire du code, ça permet juste quand on maîtrise bien d'en faire moins (les comportements ou algorithmes restent à coder quand même, mais le code est allégé des lignes de code rébarbatives)

2) CoreData : cela te permet de constituer la partie "modèle" de ton application (au sens modèle/vue/contrôleur) : par exemple si tu as déjà pratiqué l'UML, c'est un peu pareil, tu définis tes objets, leurs propriétés, les autres objets qu'ils contiennent.. tout ça avec un petit graphe (exemple vite fait trouvé sur google).
Et une fois que tu as fait ça tu as un modèle de données tout prêt, et ton appli n'a plus qu'à le manipuler (du genre rajouter des mots dans un langage, pour reprendre l'exemple).
De même, cela n'exempte pas de faire du code, mais te facilite la création de ton modèle.


Dans les 2 cas, si tu choisis d'utiliser ces 2 technologies, cela va t'éviter d'écrire certaines parties du code (et pour des applications très simples faites avec CoreData + avec les bindings, on peut même ne pas avoir de ligne de code du tout, mais bon dès qu'on veut commencer à faire un truc un peu plus sympa faut bien s'y pencher, sur le code), mais il ne faut pas pour autant éviter d'en écrire à tout prix, ce n'est qu'un outil pour t'aider et éviter le code rébarbatif.

C'est aussi pour ça que je n'en n'avais pas parlé dans mon post précédent : si tu te mets à Cocoa (avec Xcode et IB), je ne pense pas qu'il soit bon de commencer par CoreData et les bindings, pour la simple et bonne raison que tu vas être tenté par la facilité mais au final ne va pas avoir acquis les bases de Cocoa. Et quand tu auras atteint les limites de CoreData+bindings et qu'il faudra te mettre dans le code (puisqu'il faudra bien un jour ou l'autre), tu vas tomber de très haut !

Alors qu'en te mettant dès le début aux rudiments du code en Obj-C et en Cocoa, tu vas apprendre certains concepts, qui se faciliteront après quand tu utiliseras les outils comme CoreData, mais au moins tu auras de solides bases et une meilleure vision du fonctionnement du framework.


VoilĂ , je crois que tout est dit.
Sinon si tu veux juste voir à quoi ça ressemble et comment on peut faire des petites applis sympas avec peu de lignes de code (voire aucune si l'appli est assez simple) : un tuto là et un autre chez Apple cette fois peuvent te donner une idée.

Si tu es prêt à t'attaquer à l'ObjC, à Cocoa, et à coder quand même un peu pour faire ton soft personnalisé, du moment que tu as un niveau d'anglais suffisant pour lire la doc, ça semble une bonne option. Mais ça reste du développement, et je ne connais pas ton niveau dans ce domaine non plus ;)

Le posteur fou de macfr
Mon blog: Crunchy Development
______________
Devise Shadok : S'il n'y a pas de solution, c'est qu'il n'y a pas de problème...


#6 Zbooby17

Zbooby17

    Membre

  • Membres
  • Pip
  • 5 Messages :

Posté 03 avril 2007 - 11:01

Merci beaucoup pour tous tes conseils. Cela va beaucoup m'aider dans ma décision. Je vais me lancer directement en cocoa/obj-c je pense.
Néanmoins et bien que l'intégration dans Mac ne soit pas la même que pense-tu de la solution Eclipse/Java/Swing/MySQL?



Rebonsoir,

Alors il y a une solution que j'ai (volontairement) omis dans mon premier post, c'est CoreData (et les bindings que j'ai un peu évoqué).

En effet en programmant avec Xcode et InerfaceBuilder (gratuits et dispos sur le DVD fourni avec ton mac) tu peux faire des lignes de code (il faudra te mettre à l'Objective-C, langage un peu déroutant au début mais bon) pour piloter ton interface, mais il y a aussi plein de petites choses pour lesquelles tu peux te passer de lignes de code.

1) Les bindings : ils te permettent de te passer de morceaux de "glue code" comme par exemple quand on change la sélection d'une liste, mettre à jour automatiquement tous les champs qui contenaient les informations sur la ligne sélectionnée. Ou encore changer la dispobinilité ou la visibilité d'un objet suivant la valeur d'un champ (bouton OK désactivé tant que le champ est vide), etc. Plein de petits automatismes facilitant la vie de ce côté.
Ca n'empêche pas de faire du code, ça permet juste quand on maîtrise bien d'en faire moins (les comportements ou algorithmes restent à coder quand même, mais le code est allégé des lignes de code rébarbatives)

2) CoreData : cela te permet de constituer la partie "modèle" de ton application (au sens modèle/vue/contrôleur) : par exemple si tu as déjà pratiqué l'UML, c'est un peu pareil, tu définis tes objets, leurs propriétés, les autres objets qu'ils contiennent.. tout ça avec un petit graphe (exemple vite fait trouvé sur google).
Et une fois que tu as fait ça tu as un modèle de données tout prêt, et ton appli n'a plus qu'à le manipuler (du genre rajouter des mots dans un langage, pour reprendre l'exemple).
De même, cela n'exempte pas de faire du code, mais te facilite la création de ton modèle.
Dans les 2 cas, si tu choisis d'utiliser ces 2 technologies, cela va t'éviter d'écrire certaines parties du code (et pour des applications très simples faites avec CoreData + avec les bindings, on peut même ne pas avoir de ligne de code du tout, mais bon dès qu'on veut commencer à faire un truc un peu plus sympa faut bien s'y pencher, sur le code), mais il ne faut pas pour autant éviter d'en écrire à tout prix, ce n'est qu'un outil pour t'aider et éviter le code rébarbatif.

C'est aussi pour ça que je n'en n'avais pas parlé dans mon post précédent : si tu te mets à Cocoa (avec Xcode et IB), je ne pense pas qu'il soit bon de commencer par CoreData et les bindings, pour la simple et bonne raison que tu vas être tenté par la facilité mais au final ne va pas avoir acquis les bases de Cocoa. Et quand tu auras atteint les limites de CoreData+bindings et qu'il faudra te mettre dans le code (puisqu'il faudra bien un jour ou l'autre), tu vas tomber de très haut !

Alors qu'en te mettant dès le début aux rudiments du code en Obj-C et en Cocoa, tu vas apprendre certains concepts, qui se faciliteront après quand tu utiliseras les outils comme CoreData, mais au moins tu auras de solides bases et une meilleure vision du fonctionnement du framework.
VoilĂ , je crois que tout est dit.
Sinon si tu veux juste voir à quoi ça ressemble et comment on peut faire des petites applis sympas avec peu de lignes de code (voire aucune si l'appli est assez simple) : un tuto là et un autre chez Apple cette fois peuvent te donner une idée.

Si tu es prêt à t'attaquer à l'ObjC, à Cocoa, et à coder quand même un peu pour faire ton soft personnalisé, du moment que tu as un niveau d'anglais suffisant pour lire la doc, ça semble une bonne option. Mais ça reste du développement, et je ne connais pas ton niveau dans ce domaine non plus ;)



#7 AliGator

AliGator

    (Trop) Grand Bavard

  • Membres d'honneur
  • PipPipPipPipPipPipPipPipPip
  • 12 338 Messages :
  • Configuration:• MacBook Pro 15" 2,2GHz, 10.6
    • MacMini G4 1,42GHz, 10.5
  • Sexe:Masculin
  • Localisation:Rennes (Bretagne, France)
  • Passions:Piano, Cuisine, Danse (Rock, ...), faire des rĂ©ponses de 3km

Posté 03 avril 2007 - 12:17

Hello,

Alors si tu connais bien Java (et Swing), rien ne t'empêche de programmer en Java sous OSX. Que tu utilises Eclipse ou Xcode comme IDE, selon ta préférence, d'ailleurs.
Il existe même un "bridge" Cocoa/Java qui te permet d'accéder aux API Cocoa en Java (et non en Objective-C comme c'est le cas habituellement), ce qui te permettrait si tu connais déjà Java d'appréhender doucement Cocoa d'abord, et Objective-C plus tard.

Par contre si tu fais du Cocoa ce ne sera pas crossplateform, alors que si tu fais du Eclipse/Java/Swing ça le sera... mais tu n'auras pas toutes les sympatiques classes que MacOSX te met à disposition ou les avantages de pouvoir accéder directement à certains service de OSX, du coup, ce qui est logique. A toi de trouver ce qui convient le mieux. Sachant que si tu connais Java ça peut être une étape intermédiaire intéressante pour ne pas apprendre l'Objective-C tout de suite (mais te familiairiser avec Cocoa quand même), même si à terme tu en viendras certainement à l'Objective-C ;)

Pour la base de données, MySQL est une solution, mais qui nécessite l'installation d'un serveur MySQL. Si tu comptes diffuser ton application ce serait très dommageable d'obliger l'utilisateur de ton appli à installer un serveur MySQL. C'est pour ça que je te parlais de sqlite, qui est aussi à base de SQL (donc tu retrouveras la même logique) mais orienté monoposte et monoutilisateur (typiquement pour avoir une base de données locale sur un ordi).

PS : Pas besoin de reciter mon message à chacune de tes réponses (...surtout que j'ai la mauvaise habitude de faire des messages de 3km) :D

Le posteur fou de macfr
Mon blog: Crunchy Development
______________
Devise Shadok : S'il n'y a pas de solution, c'est qu'il n'y a pas de problème...


#8 Invité_Renaud_*

Invité_Renaud_*
  • Guests

Posté 03 avril 2007 - 12:30

Il existe même un "bridge" Cocoa/Java qui te permet d'accéder aux API Cocoa en Java (et non en Objective-C comme c'est le cas habituellement), ce qui te permettrait si tu connais déjà Java d'appréhender doucement Cocoa d'abord, et Objective-C plus tard.


Dans le mesure où le bridge Java a été "deprecated" (=déclaré comme obselète et donc n'évolue plus), je ne sais pas si c'est une bonne idée de suggérer cette solution.

Si on veut utiliser un autre langage qu'objective-c avec Cocoa, il vaut mieux utiliser Python (via PyObjc) ou Ruby (via RubyCocoa), qui d'après les rumeurs seront intégrés à Leopard (et qui sont déjà utilisables sous Tiger, mais qu'il faut installer à part).




0 utilisateur(s) en train de lire ce sujet

0 membre(s), 0 invité(s), 0 utilisateur(s) anonyme(s)