|
PROFESSIONAL NEWSGROUPS
WINDEV, WEBDEV and WINDEV Mobile |
| | | | | |
| WM18 Déployez sur l'apple store |
| Started by Roumégou Eric, Oct., 02 2012 4:48 PM - 8 replies |
| |
| | | |
|
| |
Posted on October, 02 2012 - 4:48 PM |
Bonjour,
sans doute avez vous pris connaissance des annonces de la 18.
moi celle qui m'interresse en WM, c'est la 372 page 45.
Est-ce à dire que l'on serait dispensé de passer par un mac ?
Merci de vos répones. |
| |
| |
| | | |
|
| | |
| |
Posted on October, 02 2012 - 5:36 PM |
Bonjour Eric
a priori non. c'est le seul moyen de développement connue pour iphone/ipad.
Il s'agit du déploiement de l'app terminée dans l'appel store pour sa vente
Cordialement
--
Fabrice Harari
Consultant WinDev, WebDev et WinDev Mobile International
Plus d'information sur http://fabriceharari.com/index_FR.html
On 02/10/2012 09:48, Roumégou Eric wrote:
Bonjour,
sans doute avez vous pris connaissance des annonces de la 18.
moi celle qui m'interresse en WM, c'est la 372 page 45.
Est-ce à dire que l'on serait dispensé de passer par un mac ?
Merci de vos répones.
|
| |
| |
| | | |
|
| | |
| |
Posted on October, 02 2012 - 7:46 PM |
Bonjour Fabrice
merci de ta réponse.
j'aurai aimé une solution car ça me gonfle de faire entrer du mac chez
moi (et surtout de faire sortir des tunes) juste pour avoir (peut être
?)une appli Iphone à développer un jour.
Bon bien sûr il y a les solutions des VM, mais j'aime pas trop.
Fabrice Harari avait énoncé :
Bonjour Eric
a priori non. c'est le seul moyen de développement connue pour iphone/ipad.
Il s'agit du déploiement de l'app terminée dans l'appel store pour sa vente
Cordialement
--
Fabrice Harari
Consultant WinDev, WebDev et WinDev Mobile International |
| |
| |
| | | |
|
| | |
| |
Posted on October, 03 2012 - 3:52 PM |
> moi celle qui m'interresse en WM, c'est la 372 page 45
Cette fonctinnalité existe déjà sur la 17 - à priori pas de changement à en attendre dans la version 18 (le processus Apple ne change pas)... |
| |
| |
| | | |
|
| | |
| |
Registered member
58 messages |
|
Posted on October, 04 2012 - 11:12 AM |
bjr,
totalement contrôlé par apple, pcsoft n'y peut rien.
par contre toi tu peux utiliser une vm pour l'étape xcode + publication.
c'est ça ou acheter un mac, entre nous la moins chère des machines est suffisante (mac mini)
--
Mac Toutim |
| |
| |
| | | |
|
| | |
| |
Posted on October, 04 2012 - 12:54 PM |
C'est vrai que c'est un peu difficile à comprendre pourquoi c'est alors indiqué comme une nouveauté de la 18 ? |
| |
| |
| | | |
|
| | |
| |
Registered member
58 messages |
|
Posted on October, 04 2012 - 3:04 PM |
c'est la possibilité de publier depuis l'iphone. ça sous-entend qu'il a fallu d'abord valider sous mac os, puis packager et transférer sur l'iphone.
une fois l'appli sur ton iphone, tu peux la publier via ton compte developpeur apple.
bref, pas grans interet si ce n'est qu'il faut bien lister 918 nouveautés
--
Mac Toutim |
| |
| |
| | | |
|
| | |
| |
Registered member
203 messages
Popularité : +3 (3 votes) |
|
Posted on October, 04 2012 - 6:46 PM |
Comme dit sur l'autre forum, c'est pas une nouveauté mais plus une info pour le lecteur qui ne connait pas Windev et qui découvre le document. De même que le déploiement sur GooglePlay qui est présenté comme une nouveauté, mais s’était déjà possible avant.
Pour la partie iOs : c'est Apple qui impose de compiler sur un vrai Mac. Compiler dans une VM est possible mais Apple peut fermer votre compte développeur pour le non respect des termes du contrat de licence.
Je ne sais pas si c'est autorisé, mais si vous êtes plusieurs développeurs vous pouvez compiler tous les projets sur le même Mac, avec un script SSH + compilation en ligne de commande.
Dans tous les cas c'est beaucoup plus pratique que chaque dev utilise son propre Mac et son propre iPhone/iPad.
En ce qui concerne une future app iPhone, rien ne vous empêche de faire une petite maquette pour tester vit fait avec une VM. Si il s’avère que WM répond à vos attentes iOs il sera toujours temps de vous équiper avec des mac.
Il y a quelques personnes qui ont fait des app iOs en Windev, dans mon cas ça n'a pas été très concluant : bugs d'ancrages, blocage des IHM lors des traitements car pas de multi-tâche/multi-threading, le comportement de l'appli dans le simulateur et sur le matériel n'est pas le même ce qui oblige à toujours tester sur l'appareil (donc compiler, déployer, installer, lancer l'appli : long et laborieux), etc ...
Par exemple quand on ouvre les exemples fournis est qu'on lance les applis sur un iPad 2 (notamment les exemples avec dessin de graphes) l'affichage se fige et on ne peut plus cliquer dans les interfaces avant la fin du traitement.
Quand on essaye de faire une fenêtre avec plusieurs champs et des ancrages spécifiques, on bascule de paysage à portrait et des champs disparaissent de l’écran. Pourtant je maitrise les ancrages en Windev.
Bref l'impression générale est un peu brouillon des les premières minutes de test.
J'attends de voir si c'est mieux en version 18.
Par contre ce qui est rassurant c'est que des fonctionnalités sont ajoutées pour iOs tout au long de l'année. Donc on peut espérer un rapide mieux.
Voila mon avis,
Alex  |
| |
| |
| | | |
|
| | |
| |
Registered member
203 messages
Popularité : +3 (3 votes) |
|
Posted on October, 04 2012 - 7:12 PM |
Dernier point concernant iOs (celui qui ma déconcerté le plus je crois) : la gestion des fenêtres.
On n'a pas de fonction Ouvre mais OuvreFille. La fonction Ouvre : ouvre une fenêtre et attend sa fermeture pour continuer à exécuter le code qui suit (en tout cas sous Windows). La fonction OuvreFille sur iOs : ouvre la fenêtre et continue à exécuter le code suivant sans attendre la fermeture.
Conséquence : si vous avez un code qui ouvre une fenêtre pour identifier un utilisateur et attend la valeur de retour pour continuer (identifié oui/non), et bien la fenêtre s'ouvre et le code continue alors que l'utilisateur n'a cliqué sur rien.
J'ai voulu porter une appli Windows. L'appli ouvre toutes les fenêtres à partir de méthodes de classes. Et toutes les fenêtres sont bloquantes et donnent des valeurs de retours. Il n'y a pas non plus de fenêtre principale dans le projet. C'est la classe user qui décide de montrer l’écran d'identification ou pas selon les options utilisateur (connexion auto ou pas).
Et bien je dois revoir complétement toute ma gestion des fenêtres car tous les appels de méthodes ouvrent la fenêtre et exécutent la suite du code sans attendre la valeur de retour. Je dois revoir aussi complétement tout le processus de démarrage de l'appli et toute la gestion des données dans les fichiers ini, etc ... Sans parler de la surcharge de dizaines de fonctions Windev pour gérer le cas Android et iOs. En bref le portage de mon appli Windows va être long et laborieux.
Cordialement,
Alex |
| |
| |
| | | |
|
| | | | |
| | |
| | |
| |
|
|
|