TIOBE: Delphi is on its way out

[mamcx]

Empezado por Al González

Mario, si trabajaras en Embarcadero y te preguntaran ¿qué podemos hacer para que FireMonkey sea mejor o por lo menos tan bueno como Cocoa Touch?, ¿qué sugerirías? De tu meditada respuesta puede surgir alguna buena idea para tomarse en cuenta.
.

Que es lo que hace a delphi una herramienta superior en Windows? Inventarse una libreria alienigena a la plataforma donde corre y "pintarla" para taparlo? Al contrario, es construir sobre esa plataforma y ofrecer un nivel de abstracción mejor.

Firemonkey es un intento de crear una libreria unificada para todas las plataformas. Esa es la estrategia de Java, y su éxito solo ha sido a los programadores que no les interesa hacer la mejor app posible sino simplemente tener su app en el mayor numero de plataformas. Es por eso que multiplataforma en el nivel de la GUI siempre ha sido equivalente a una interface mediocre (no muy mala, no muy buena, mediocre). Eso es lo que la gente le choca de "Java" y otras librerias similares.

El problema, es que al contrario del API de windows, Coccoa Touch es un (conjunto) de frameworks muy bien pensado. En muchos aspectos, mas avanzados que la VCL. Sin embargo, todo se puede mejorar y simplificar, por ejemplo hace dias vi https://github.com/clayallsopp/formotion (eso que muestra ahorra un monton de trabajo!).

Osea, si soy alguien que quiero tener la mejor app (a nivel de GUI) firemonkey ni me va ni me viene. Como dije antes, uno puede programar Winforms desde delphi, pero para que? Lo que me interesa es poder sacar provecho, no solo a un API mas completo, y superior, que cualquier intento de crear una GUI multiplataforma, sino que me da acceso a todos los componentes disponibles en el mercado (ej: http://www.cocoacontrols.com/platforms/ios/controls). Ganar firemonkey y perder Coccoa Touch no tiene gracia.

Ganar Firemonkey y poder usar Coccoa Touch sin problemas? Eso es *muy distinto*. Es lo mismo con windows: Ganas VCL y puedes usar API Win32. Es win-win. Si te sale mejor con VCL, genial, sino, no hay problema.

Y mejorar firemonkey, por lo que he visto es complicado. Conceptualmente no lo entiendo muy bien. Siendo coccoa touch complicado -como todo api grande- es muy facil de entender como se construyen nuevos controles. Son como 4 cosas que debes entender (Todo es un UIView, se construye con capas, usas datasources virtuales y haces delegados. Eso es todo). Lo hago de forma habitual todo el tiempo, y sin lios.

Empezado por Al González

¿Por qué esa tendencia a pensar que Delphi las tiene de perder donde otros han sido los primeros? ¿Acaso no podemos, comunidad + fabricante, ponernos las pilas para hacerlo competitivo en esos terrenos? ¿No se dispone de capital, medios, profesionales cualificados y putas ganas para lograrlo?
.

Yo no pienso eso! Ser primero es mucha ventaja, pero el segundo tiene la ventaja de ver el pasado y mejorarlo (prácticamente, esa es la estrategia de Apple ).

El problema es que los que han manejado Delphi no han tenido una estrategia que conduzca a todo eso. Y mucha gente de la comunidad se ha cansado, gente con talento.

Empezado por Al González

¿Podrías dedicar el tiempo que sea necesario, en tu siguiente mensaje, para exponer un ejemplo contundente, sin margen de ambigüedades, argumentado con paciencia y sin limitarte a presentar meras referencias Web, que deje claro, sin lugar a dudas, las diferencias de calidad y productividad entre Cocoa Touch y el FireMonkey de Delphi XE4?

Me la pones dificil! Sin *referencias*! si eso es lo que mas me gusta! La diferencia se nota en las mismas apps, su fluidez, desempeño, y versatilidad. Has usado un iPhone o iPad? Solo es comparar las apps que alli se ven con las que se ven en windows.

En fin, te pongo ejemplos, sacados de mis proyectos (asi que no son de lo mejor, porque programador de GUI no soy):

Asi es como se anima una transicion, con efecto de "pasar pagina", a pesar que donde hago eso, hay cientos de controles graficos. Cero problemas de desempeño:

Código PHP:

- (IBAction)saveDocument:(id)sender {
    if ([self saveRecord]) {
        [UIView transitionWithView:self.view
                          duration:0.7
                           options:UIViewAnimationOptionTransitionCurlDown
                        animations:^{
                            [self newDocument:0];
                        } completion:^(BOOL finished) {
                        }];
    }
} 


Asi es como puedo graficar miles de imagenes, sin problemas de desempeño:

Código PHP:

// The cell that is returned must be retrieved from a call to -dequeueReusableCellWithReuseIdentifier:forIndexPath:
- (UICollectionViewCell *)collectionView:(UICollectionView *)collectionView cellForItemAtIndexPath:(NSIndexPath *)indexPath {
    ProductIconViewCell *cell = (ProductIconViewCell *)[collectionView dequeueReusableCellWithReuseIdentifier:@"IconCell" forIndexPath:indexPath];
    
    NSDictionary *p = self.data[indexPath.row];
    NSString *img = [p objectForKey:@"imageName"];
    NSString *imgFile = [[p objectForKey:@"image"] lastPathComponent];
    
    cell.imageBtn.tag = indexPath.row;
    [cell.imageBtn setBackgroundImage:[UIImage imageNamed:imgFile] forState:UIControlStateNormal];
    cell.title.text = img;

    [cell.imageBtn setTitle:self.ref forState:UIControlStateNormal];

    return cell;
} 


Asi convierto un HTML a un PDF, el HTML esta full con CSS3:

Código PHP:

    DDLogInfo(@"Report HTML %@", templatePath);

    NSError * error;
    
    content = [GRMustacheTemplate renderObject:self
                                                fromString:content
                                                     error:&error];
    
    [content writeToFile:[@"~/Documents/demo.html" stringByExpandingTildeInPath] atomically:YES encoding:NSUTF8StringEncoding error:nil];

    if (error && [self.delegate respondsToSelector:@selector(reportFail:)]) {
        [self.delegate reportFail:error];
    }


[NDHTMLtoPDF createPDFWithHTML:content
                                         pathForPDF:[@"~/Documents/demo.pdf" stringByExpandingTildeInPath]
                                           delegate:self
                                           pageSize:kPaperSizeA4
                                            margins:UIEdgeInsetsMake(10, 5, 5, 5)]; 


QUiero visualizar un conjunto de datos igual a http://pinterest.com/all/, control el cual no existe. Asi que necesito inventarmelo (y los que mire open source no me gustaron):

Código PHP:

//
//  NewsListViewController.m
//  DisplayNews
//
//  Created by mamcx on 15/03/13.
//  Copyright (c) 2013 El malabarista. All rights reserved.
//

#import "NewsListViewController.h"

@implementation NewsListCell

- (UILabel *) buildLabel:(NSString *)className {
    UILabel *label = [[UILabel alloc] init];
    label.autoresizingMask = UIViewAutoresizingFlexibleLeftMargin | UIViewAutoresizingFlexibleRightMargin | UIViewAutoresizingFlexibleTopMargin | UIViewAutoresizingFlexibleBottomMargin;
    label.backgroundColor = [UIColor clearColor];
    
    [NUIRenderer renderLabel:label withClass:className];

    return label;
}

- (id)initWithFrame:(CGRect)frame
{
    self = [super initWithFrame:frame];
    if (self) {
        // Initialization code        
        self.lbTitle = [self buildLabel:@"LargeLabel"];
        self.lbTitle.lineBreakMode = NSLineBreakByWordWrapping;
        self.lbTitle.numberOfLines = 0;

        self.lbDate = [self buildLabel:@"NormalLabel"];
        self.lbSource = [self buildLabel:@"NormalLabel"];

        [self addSubview:self.lbTitle];
        [self addSubview:self.lbDate];
        [self addSubview:self.lbSource];
    }

    return self;
}

- (void) layoutSubviews {
    [super layoutSubviews];
    
    self.lbDate.frame = CGRectMake(10, 5, self.frame.size.width - 20, 20);
    [self.lbDate sizeToFit];
    
    self.lbTitle.frame = CGRectMake(0, self.lbDate.frame.size.height + 6, self.frame.size.width - 20, self.frame.size.height - self.lbDate.frame.size.height*2 - 6);
    self.lbTitle.center = CGPointMake(self.frame.size.width/ 2, self.frame.size.height/2);
    
    [self.lbSource sizeToFit];
    self.lbSource.frame = CGRectMake(10, self.frame.size.height - self.lbSource.frame.size.height - 6, self.frame.size.width - 20, self.lbSource.frame.size.height);
    
    [NewsSource adjustFontSizeToFit:self.lbTitle from:14 to:60];
}
@end

@interface NewsListViewController ()

@end

@implementation NewsListViewController

- (void)viewDidLoad
{
    [super viewDidLoad];

    self.delegate = self;
    
    self.onSingleTap = ^(UIView* view, NSInteger viewIndex){
        NSLog(@"Single press on %@, at %d", view, viewIndex);
        
        [[NSNotificationCenter defaultCenter]
            postNotificationName:NOTIFY_SHOW_NEW object:[NSNumber numberWithInt:viewIndex] userInfo:nil];
        
        __weak NewsListViewController *weakSelf = self;
        
        [weakSelf.navigationController popViewControllerAnimated:YES];
    };

    self.onLongPress = ^(UIView* view, NSInteger viewIndex){
        NSLog(@"Long press on %@, at %d", view, viewIndex);
    };
    
    self.onDoubleTap = ^(UIView* view, NSInteger viewIndex){
        NSLog(@"Double tap on %@, at %d", view, viewIndex);
    };

    [self reloadData];
}

- (void)tableView:(UITableView *)tableView willDisplayCell:(UITableViewCell *)cell forRowAtIndexPath:(NSIndexPath *)indexPath {
    BDDynamicGridCell *theCell = (BDDynamicGridCell*)cell;
    
    theCell.gridContainerView.backgroundColor = [UIColor lightGrayColor];
    
    for (UIView *v in theCell.gridContainerView.subviews) {
        //[NUIRenderer render:v];
        v.backgroundColor = self.view.backgroundColor;
    }
}

- (NSUInteger)numberOfViews
{
    return [NewsSource SourceDB].newsItems.count;
}

-(NSUInteger)maximumViewsPerCell
{
    return 3;
}

- (UIView *)viewAtIndex:(NSUInteger)index rowInfo:(BDRowInfo *)rowInfo
{
    
    NewsListCell * cell = [[NewsListCell alloc] initWithFrame:CGRectMake(0, 0, 300, 300)];
   
    FeedItem *item = [NewsSource SourceDB].newsItems[index];
    
    cell.lbTitle.text = item.item.title;
    cell.lbDate.text = [[NewsSource SourceDB] formatDate: item.item.date];
    cell.lbSource.text = item.source.name;
    
    return cell;
}

- (BOOL)shouldAutorotateToInterfaceOrientation:(UIInterfaceOrientation)toInterfaceOrientation
{
    //Call super when overriding this method, in order to benefit from auto layout.
    [super shouldAutorotateToInterfaceOrientation:toInterfaceOrientation];
    return YES;
}

- (void)willRotateToInterfaceOrientation:(UIInterfaceOrientation)toInterfaceOrientation duration:(NSTimeInterval)duration {
    [self reloadData];
}

- (CGFloat)rowHeightForRowInfo:(BDRowInfo *)rowInfo
{
    return 300;
}
@end 


P: La parte visual se hace con Interface Builder, no tan bueno como el diseño en Delphi, pero apenas suficiente. De todo lo anterior, es notable lo poco código que requieren, excepto por lo largos que son los metodos en obj-c.

Animar, rotar, graficar, componer controles en base a otros, alimentar los datos no importan lo bastante que sean, a pesar de correr en maquinas menos potentes que un PC, y aplicar efectos y estilos visuales atractivos, son las cosas que programadores normales como yo podemos hacer, sin problemas y sin sudar mucho.

Hay muchas cosas que salen genial. Es dificil sin apuntar a algo concreto (no se si les parecera mucha gracia mis ejemplos, a mi si porque la programacion GUI no es mi fuerte ). Por ejemplo, necesito hacer una tarea en el "background" sin frenar la GUI:

Código PHP:

dispatch_async(queue, ^{
        self.inventory = [Product retrieveInventoryItems];
        dispatch_async(dispatch_get_main_queue(), ^{            
            lbHello.text = @"Inventory Loaded\n\nHow can I help you?";
        });
    }); 


O necesito notificar (broadcast) a todo el que escuche que algo paso:

Código PHP:

[[NSNotificationCenter defaultCenter] postNotificationName:DB_RECORD_CHANGED object:ds userInfo:nil]; 


En fin, Coccoa Touch es el equivalente a la VCL (ya que no solo cubre la parte visual, sino que ademas maneja otras sub-apis, como las de audio, multimedia, sqlite, mapas y otros)

[[Al González]]

Prometo dejar de alimentar a los troles.

Empezado por mamcx

Firemonkey es un intento de crear una libreria [sic] unificada para todas las plataformas. Esa es la estrategia de Java, y su éxito solo ha sido a los programadores que no les interesa hacer la mejor app posible sino simplemente tener su app en el mayor numero de plataformas.

Entonces, dado que Java fracasó en la calidad de sus aplicaciones, FireMonkey también lo hará, ¿esa es la lógica?

Empezado por mamcx

El problema, es que al contrario del API de windows, Coccoa [sic] Touch es un (conjunto) de frameworks muy bien pensado. En muchos aspectos, mas avanzados que la VCL.

Pues eso para mí no es un problema, sino una buena oportunidad de mejorar nuestros desarrollos para iOS. Vuelvo a preguntar: ¿qué se necesita para usar Cocoa Touch desde Delphi?

Empezado por mamcx

Ganar Firemonkey y poder usar Coccoa Touch sin problemas? Eso es *muy distinto*. Es lo mismo con windows: Ganas VCL y puedes usar API Win32.

Insisto, ¿de qué forma se podría?

Empezado por mamcx

Y mejorar firemonkey, por lo que he visto es complicado. Conceptualmente no lo entiendo muy bien.

¡Ajá! Eso ya lo venía sospechando.

Empezado por mamcx

El problema es que los que han manejado Delphi no han tenido una estrategia que conduzca a todo eso.

¿Alguna idea para ellos? De ser posible, bien redactada.

Empezado por mamcx

Me la pones dificil! Sin *referencias*!

Ese es el problema de no saber leer (o sí saber, pero hacerlo a las carreras, sin el debido interés).

Empezado por Al González

[...] sin limitarte a presentar meras referencias Web [...]

Empezado por mamcx

Has usado un iPhone o iPad?

Por ahora, apenas dos o tres toques de pantalla en el teléfono de un familiar. Muy llamativas interfaces de usuario, por cierto. ¿Y tú...

Empezado por egostar

[...] ¿has hecho alguna aplicación iOS con XE4?

Esa pregunta aún no ha sido respondida.

Empezado por mamcx

En fin, te pongo ejemplos, sacados de mis proyectos...

Sí, gracias, pero ese código no me dice nada. ¿No se puede conseguir lo mismo con FMX o con acceso directo a Cocoa Touch desde Delphi? ¿Te parece si nos ponemos a adaptar FMX a Cocoa? ¿Mucho trabajo? Sólo un poco más del que dedicamos a quejarnos y debatir, creo yo...

Empezado por mamcx

En fin, Coccoa [sic] Touch es el equivalente a la VCL (ya que no solo cubre la parte visual, sino que ademas maneja otras sub-apis, como las de audio, multimedia, sqlite, mapas y otros)

Reitero, ¿sabes cómo podríamos aprovecharla desde Delphi, ahora que tenemos la posibilidad de generar aplicaciones para iOS?

No dudo que tengas la experiencia necesaria en iOS como para acarrear esos aires de suficiencia, pero un poco de paciencia y serena orientación para los plebeyos ignorantes que apenas vamos ingresando a ese mundo no estaría mal. Ábrete un poco a la idea de que muy pocas cosas en este planeta son imposibles. Si ya pueden crearse con Delphi aplicaciones para iOS, posiblemente de mayor calidad que las de Java, y muy pronto para Android también (que en mi opinión tendrá más valor), creo que deberíamos estar de plácemes los programadores de este lenguaje. Seguramente pediremos (pues es casi nuestra obligación) que se mejoren los particulares aspectos que veamos mal de XE4, pero primero hay que conocer esos aspectos. No dar por hecho que todo está mal sólo porque algo no entendimos o porque no nos gustó la forma en que fue diseñado en una pasada versión.

Como te comenté en otra ocasión, mi estimado Mario, arrima el hombro más allá de la crítica. La Comunidad Delphi te necesita.

Saludos.

[Casimiro Notevi]

Hay algo que me llama la atención, normalmente se le "exige" a delphi que sea lo mejor para windows, y ahora que sea bueno para ios, android, osx, 32 y 64 bits, etc.
Si hablamos de lazarus entonces es el "remate de los tomates", queremos que funcione en todo lo anterior y además en todo tipo de cpus, sistemas operativos, smartphones, tablets, etc. con cualquier combinación de hard/soft.
Sin embargo, cuando se habla de ios ¿en qué sistemas funciona?, osx ¿en qué sistemas funciona?, coccoa ¿en qué sistemas funciona?, todos ellos son de apple y sólo funcionan en algunos sistemas de apple. Punto. No tienen que complicarse la vida para hacerlo funcionar en ningún otro lugar.
No se le puede "exigir" a un producto "externo" (sea delphi o cualquier otro) que sea "mejor" que algo creado por el fabricante y dueño de ese producto/sistema.
Y lo digo yo, que reniego de la política de marketing que lleva embarcadero, que creo que es mala para ellos y para nosotros, porque quiero/queremos lo mejor para delphi.

[Casimiro Notevi]

Y en cuanto a la estadística tiobe, pongo un ejemplo: hagamos una búsqueda de marcas de coches, ¿cuáles devolverán más entradas en una búsqueda en google?, seguramente renault, peugeot, citroen, ford, etc. ¿quiere decir que son mejores que otras marcas que aparecen menos (bmw, mercedes, etc.)?, seguro que no, pues eso.

[[egostar]]

Empezado por Casimiro Notevi

Hay algo que me llama la atención, normalmente se le "exige" a delphi que sea lo mejor para windows, y ahora que sea bueno para ios, android, osx, 32 y 64 bits, etc.
Si hablamos de lazarus entonces es el "remate de los tomates", queremos que funcione en todo lo anterior y además en todo tipo de cpus, sistemas operativos, smartphones, tablets, etc. con cualquier combinación de hard/soft.
Sin embargo, cuando se habla de ios ¿en qué sistemas funciona?, osx ¿en qué sistemas funciona?, coccoa ¿en qué sistemas funciona?, todos ellos son de apple y sólo funcionan en algunos sistemas de apple. Punto. No tienen que complicarse la vida para hacerlo funcionar en ningún otro lugar.
No se le puede "exigir" a un producto "externo" (sea delphi o cualquier otro) que sea "mejor" que algo creado por el fabricante y dueño de ese producto/sistema.
Y lo digo yo, que reniego de la política de marketing que lleva embarcadero, que creo que es mala para ellos y para nosotros, porque quiero/queremos lo mejor para delphi.

Exacto, a eso me he referido y parece que no me he explicado correctamente, pero Casimiro ha dado en el clavo, Delphi está en camino de tener lo que cualquiera desearía, con muchos obstaculos y algunos errores que han ido corrigiendo en el camino, y me uno a la pregunta de Casimiro ¿con el tal "coccoa" puedes programar aplicaciones para windows?

Yo realmente estoy complacido con la forma como se desarrollan app's para iOS y como funciona en esos dispositivos desde la comodidad de Delphi, no tengo que aprender otro lenguaje, no tengo que preocuparme por como lo hace, simplemente compilo y ya. Por algo es un RAD ¿ o no ?

Por último, como siempre digo, usar éste o aquel producto "depende, depende, depende" del mercado que te hayas decidido a atacar y en algo estoy de acuerdo con diegofhernando, cada quien desarrolla en lo que le permite realizar sus actvidades cómodamente, pero de eso a que delphi esté por morir, hay mucha distancia.

Saludos

[mamcx]

Empezado por Al González

Entonces, dado que Java fracasó en la calidad de sus aplicaciones, FireMonkey también lo hará, ¿esa es la lógica?

Eso se devuelve. Firemonkey ha mostrado que NO es así? Donde están las apps hechas en firemonkey, donde se ve la innovacion? Que es lo que se muestra con eso que haga pensar que es una idea genial?

YO NO TENGO QUE DEMOSTRARLO. Eso es lo que debe hacer embarcadero. Como he dicho, como desarrollador de iOS, que tiene X4 que me haga dudar y me haga cambiar? Ya he dicho que no me gusta los lenguajes hechos en C - y que me gusta mucho pascal- Asi que tienen la mitad de la batalla ganada.

Pero la parte grafica? Firemonkey, lo conocen de verdad? Porque no solo es mi experiencia sino la de muchos que esta plagado de bugs.

Empezado por Al González

Pues eso para mí no es un problema, sino una buena oportunidad de mejorar nuestros desarrollos para iOS. Vuelvo a preguntar: ¿qué se necesita para usar Cocoa Touch desde Delphi?

No entiendo porque me preguntas a mi. Es cosa de que EMBT de la opcion y que sea buena. Por lo que he leido y todo, no hay suficiente.

Es importante recalcar, que no solo estoy metido con obj-c/xcode sino que evaluo las opciones (todas las que puedo) y en este momento he probado a varios proyectos alternativos. Un ejemplo de como se hace bien, es rubymotion y http://xamarin.com/monotouch. O tambien http://www.coronalabs.com/.

Empezado por Al González

¡Ajá! Eso ya lo venía sospechando.

No soy tan experto en firemonkey. Pero le he dado su oportunidad. Funcionando en windows, es una decepcion (mucho mejor winforms, que es malo). En OSX, es algo muy pobre. Luego esta el como trabajo y como se hacen las cosas. Han intentado hacer controles con firemonkey? Yo si.

Empezado por Al González

¿Alguna idea para ellos? De ser posible, bien redactada.

No se que mas decir que lo que he escrito en los foros de delphi y en estos.

Empezado por Al González

Por ahora, apenas dos o tres toques de pantalla en el teléfono de un familiar. Muy llamativas interfaces de usuario, por cierto. ¿Y tú...

Pues parece que soy el mas conocedor de la plataforma (por lo menos en este hilo). Seria bueno que le saquen un rato y miren como es. Y que me digan, sino aspiran a hacer cosas asi de buenas. Eso es lo que me gusta desde que estoy con osx, no solo el reto es MAS alto (al ver tantas apps buenas, y no como lo normal en windows, a uno le da verguenza hacer todo mediocre).

Empezado por Al González

Esa pregunta aún no ha sido respondida.

Si he usado Firemonkey. Intente hacer un proyecto completo en el. Al final? Lo tire a la basura. La funcionalidad basica es pobre y intentar irse mas lejos era muy complicado.

Empezado por Al González

Sí, gracias, pero ese código no me dice nada. ¿No se puede conseguir lo mismo con FMX o con acceso directo a Cocoa Touch desde Delphi? ¿Te parece si nos ponemos a adaptar FMX a Cocoa? ¿Mucho trabajo? Sólo un poco más del que dedicamos a quejarnos y debatir, creo yo...

Y bueno, que tal si lo intentan? Yo pongo mis cartas, pongan las suyas.

Empezado por Al González

Seguramente pediremos (pues es casi nuestra obligación) que se mejoren los particulares aspectos que veamos mal de XE4, pero primero hay que conocer esos aspectos. No dar por hecho que todo está mal sólo porque algo no entendimos o porque no nos gustó la forma en que fue diseñado en una pasada versión.

Y eso me gustaría. Pero el punto que he tratado de comunicar es que lo que hay ahora no alcanza, osea, desde EMBT/Delphi. Si fuera algo que uno pudiera arreglar, y que hubiera la posibilidad en la comunidad, pero en primer lugar, la actitud de "no me importa si no hay controles nativos, lo que me importa es no esforzarme" no ayuda. Luego esta que no hay cultura entre los programadores de windows en hacer cosas visualmente eficaces. Luego que cosas como http://www.kickstarter.com/projects/...22/nakeymonkey no despegan, y que en los foros de EMB a pocos les importa realmente sacar el jugo a la plataforma. Luego que Delphi esta por las nubes, y el acceso a IOS vale lo mismo que otro delphi. Luego que FM esta plagado de bugs. Luego que viene iOS7 y mientras xamarin actualiza su herramienta casi a la semana y estamos montados en lo ultimo, con EMBT uno queda fregado (como quedaron mis intentos con firemonkey antes).

Son muchas cosas que se van sumando.

[[movorack]]

...............

Empezado por GerixSoft

So, in order to create 100% native Cocoa applications in Delphi XE2 you will have to master the following:

1. Create simple OSX console application
   Learn how to create OSX console application in Delphi XE2 and debug it using PAServer (configure the environment, etc)
2. Enhance OSX console Delphi application w/ simple NSApplication & NSApplicationDelegate code
   Learn the very basic of Cocoa: NSApplication & NSApplicationDelegate class/protocol — I recommend to study SampleNibblesApp source code thoroughtly
3. Learn Cocoa, Xcode and how to design your interface in Xcode
   This is the most hard -- you must learn some Objective-C basics, Cocoa hierarchy, Xcode interface and how to create GUI in Xcode. I recommend to review AppleProgramming YouTube channel from the very beginning till very end.
4. Enhance OSX Delphi application w/ loading of compiled NIBs
   You must be able to design Cocoa GUI in Xcode, compile XIB to NIB, write code in Delphi to load that NIB, implement IBOutlet and IBAction handlers in Delphi.

Fuente:http://www.gerixsoft.com/blog/delphi...out-firemonkey

[[egostar]]

.....(al ver tantas apps buenas, y no como lo normal en windows, a uno le da verguenza hacer todo mediocre)......

Hay caramba!!!!!

Cuando programe para iOS, OSX con coccoa y demás yerbas, regreso para hablar de frente a frente, perdone usted mi mediocridad por hacer aplicaciones para windows.

Lo que hay que leer en estos dias.......

saludos.......

[[ElDioni]]

Empezado por mamcx

Pues parece que soy el mas conocedor de la plataforma (por lo menos en este hilo). Seria bueno que le saquen un rato y miren como es. Y que me digan, sino aspiran a hacer cosas asi de buenas. Eso es lo que me gusta desde que estoy con osx, no solo el reto es MAS alto (al ver tantas apps buenas, y no como lo normal en windows, a uno le da verguenza hacer todo mediocre).

Entonces los programas que están en las dos plataformas (photoshop, Freehand, Skype, Office) ¿en IOS son maravillosas y en Windows son mediocres?, creo que has valorado muy a la ligera y de forma muy general todos los programas hechos para windows, creo.

Saludos.

[MAXIUM]

Delphi es muy caro comparado con el resto que incluso llega a ser gratuito y libre aúnque no destaquen por el mejor IDE cumplen con lo esperado.

He ahí la falta de incentivo de parte de nuevos programadores que tienen acceso a otras herramientas sin tantas complicaciones.

Lo otro es el mercado. La mayoría esta por los moviles, principalmente con Android.

Las empresas que han tomado el rumbo de Delphi, van muy lentos con respecto a los avances y con lo que se necesita en la actualidad.

[[gatosoft]]

Empezado por MAXIUM

Delphi es muy caro comparado con el resto que incluso llega a ser gratuito y libre aúnque no destaquen por el mejor IDE cumplen con lo esperado.

He ahí la falta de incentivo de parte de nuevos programadores que tienen acceso a otras herramientas sin tantas complicaciones.

Lo otro es el mercado. La mayoría esta por los moviles, principalmente con Android.

Las empresas que han tomado el rumbo de Delphi, van muy lentos con respecto a los avances y con lo que se necesita en la actualidad.

De acuerdo, al no ser una herramienta de facil acceso su evolución va a ser mas lenta... si fuera mas económica todos aqui ya estariamos probando y bombardeando firemonkey lo cual facilitaría su desarrollo.

Al parecer embarcadero ve a firemonkey como una inversion a muy corto plazo... quiere con el recaudo indmediato de precio por licencia recuperar lo que invirtíó en la compra y adecuación del framework....

Si le apostara a mas largo plazo, con un costo mucho menor, que permitiera la masificación, le iría mejor.

[Julián]

Empezado por ElDioni

Entonces los programas que están en las dos plataformas (photoshop, Freehand, Skype, Office) ¿en IOS son maravillosas y en Windows son mediocres?

Efectivamente así es. Aunque el ejemplo Photoshop no es un caso típico, pues la suite de Adobe usa sus propios "widgets" para ventanas, botones, etc. En cuanto a las demás, excepto quizás Office, son muy superiores, en apariencia, faciliddad de configuración y facilidad de uso, a sus versiones de Windows, y esto es, evidentemente, por la gran superioridad de COCCOA.

Me parece a mi que algunos opinais muy a la ligera sobre OSX e iOS, sin haberlo usado, o como mucho con "dos o tres toques de pantalla". Y las opiniones acusando de "soberbia" y no se que mas al amigo mamcx estan de sobra, pues este se limita a opinar sobre productos de software, a dar su opinión, que puede ser tan válida o tan equivocada como la de cualquiera. Si no os gsuta su opinión exponed la vuestra, dad argumentos, opinad. Como hace él. Si a alguien no le gusta su opinión sobre Windows o Delphi, y el único recurso que le queda es decirle "soberbio" será que no tiene otro argumento.

Yo vengo usando varios años ya OSX y estoy al 100% de acuerdo con mamcx, y creo que le pasa lo mismo que a mi: que no piensa que el problema de Embarcadero sea suyo o mio, sino de Embarcadero. Yo he probado algunas versiones de Delphi después de la 7 y me parecen una mierdecilla. Muy cara, además.

Como dice Al Gonzalez, seria perfecto que Embarcadero permitiera usar COCCOA igual que en Win permite usar su API. Si no es así será porque no pueden, o porque no quieren, o porque no les dejan. Lo mismo valdría para GNOME. Pues peor para ellos, y con su pan se lo coman. Si fuera opensource si que podrían pedir ayuda a la comunidad de usuarios, pero no lo es. Y con el precio que tiene me trae sin cuidado lo que les pase. Por mi como si desaparece. Simpre nos quedará FPK y Lazarus.

Un saludo.

[[Al González]]

Empezado por movorack

¡Vaya! Por fin una respuesta constructiva. Gracias, Miguel. Estuve buscando sin éxito ese tipo de información.

Entonces, inviable no es.

[[egostar]]

Empezado por Julián

Efectivamente así es. Aunque el ejemplo Photoshop no es un caso típico, pues la suite de Adobe usa sus propios "widgets" para ventanas, botones, etc. En cuanto a las demás, excepto quizás Office, son muy superiores, en apariencia, faciliddad de configuración y facilidad de uso, a sus versiones de Windows, y esto es, evidentemente, por la gran superioridad de COCCOA.

Me parece a mi que algunos opinais muy a la ligera sobre OSX e iOS, sin haberlo usado, o como mucho con "dos o tres toques de pantalla". Y las opiniones acusando de "soberbia" y no se que mas al amigo mamcx estan de sobra, pues este se limita a opinar sobre productos de software, a dar su opinión, que puede ser tan válida o tan equivocada como la de cualquiera. Si no os gsuta su opinión exponed la vuestra, dad argumentos, opinad. Como hace él. Si a alguien no le gusta su opinión sobre Windows o Delphi, y el único recurso que le queda es decirle "soberbio" será que no tiene otro argumento.

Yo vengo usando varios años ya OSX y estoy al 100% de acuerdo con mamcx, y creo que le pasa lo mismo que a mi: que no piensa que el problema de Embarcadero sea suyo o mio, sino de Embarcadero. Yo he probado algunas versiones de Delphi después de la 7 y me parecen una mierdecilla. Muy cara, además.

Como dice Al Gonzalez, seria perfecto que Embarcadero permitiera usar COCCOA igual que en Win permite usar su API. Si no es así será porque no pueden, o porque no quieren, o porque no les dejan. Lo mismo valdría para GNOME. Pues peor para ellos, y con su pan se lo coman. Si fuera opensource si que podrían pedir ayuda a la comunidad de usuarios, pero no lo es. Y con el precio que tiene me trae sin cuidado lo que les pase. Por mi como si desaparece. Simpre nos quedará FPK y Lazarus.

Un saludo.

Bueno, como el que "acusó" de soberbia a mamcx fuí yo, me doy por aludido, y sustento lo dicho por el simple hecho de que la herramienta que uses no te da la excelencia, sino la habilidad, gusto, experiencia, "don" que tengas como programador, se pueden hacer aplicaciones "mediocres" tanto en apple como en windows, no es garantía una de otra. Pero argumentar que solo en apple se hacen bellezas si que me parece soberbia, si a ti no, está perfecto, a mi si me lo parece.

Saludos

[[nlsgarcia]]

Club Delphi,

Les comento:

1- Delphi es la herramienta RAD #1 para el desarrollo bajo Windows, sin embargo hay nuevas plataformas en pleno auge actualmente en las cuales Delphi no es competitivo.

2- Delphi es muy costoso y hay lenguaje más accesibles, populares y técnicamente mejor enfocados para el desarrollo multiplataforma o en una plataforma particular lo cual hace menos probable su uso para este fin a nuevos programadores, sin embargo ofrece capacidades multiplataforma para los programadores que tengan como opción primaria el desarrollo bajo Windows y ya posean una licencia de Delphi con dichas opciones o quieran hacer la actualización correspondiente.

3- Embarcadero ha invertido importantes recursos en hacer de Delphi un lenguaje más robusto, moderno y multiplataforma, pero aún hay puntos por mejorar y es probable que a futuro exista un Delphi XE(?) multiplataforma solido y competitivo, siempre y cuando haga un uso adecuado de las APIs de las plataformas objetivo, de la misma forma que lo hace la VCL en Windows.

4- Delphi estará vigente por muchos años independientemente de la opciones multiplataforma que llegue a consolidar, simplemente por la base instalada de aplicaciones bajo Windows actualmente en operación.

5- Embarcadero debe revisar su política de mercadeo relacionada a Delphi y hacerlo atractivo a las nuevas generaciones de programadores, las universidades son un punto importante a retomar para hacer a Delphi un lenguaje popular nuevamente.

6- Delphi no tiene que ser necesariamente el mejor lenguaje de desarrollo en todas la plataformas, pero si debe ser una opción accesible para ser considerada viable por nuevos programadores.

7- Delphi XE4 sentara las bases de la próxima generación de Aplicaciones Multiplataforma y Cloud Computing:

Delphi XE4 : http://www.embarcadero.com/es/products/delphi

Database and Cloud Connectivity with Delphi : http://www.embarcadero.com/es/products/delphi/connect

Conclusión: La historia de Delphi continuara si y solo si Embarcadero mantiene su enfoque multiplataforma y de desarrollo del lenguaje junto con una revisión de su política de mercadeo para facilitar la captación de nuevos programadores.

Espero sea útil

Nelson.

[mamcx]

Empezado por ElDioni

¿en IOS son maravillosas y en Windows son mediocres?

Fue fuerte llamarlo mediocre. Mas bien, el punto que quiero comunicar es que el nivel grafico/experiencia de usuario en OSX/iOS es consistente mas alto que las demás plataformas.

Ya que la mayoría de las apps que se hacen son de IT, al interior de las empresas, donde la calidad del software y experiencia de usuario importa poco (osea, apps corporativas) lo "normal" es ver aplicaciones mediocres. En OSX/iOS es mas común que las app sean para usuarios finales, donde son trabajadas por startups, individuos o pequeñas empresas que se esfuerzan mas por hacer aplicaciones "soyadas". Eso es un punto que influye mucho en la calidad final.

Eso termina "pegandose". Y de pronto, es habitual esforzarse por tener un icono bueno, una tipografia buena, un esquema de colores decente, y preocuparse por cosas que antes no me preocupaban y que por los programas que veo a diario no preocupan mucho...

[[Al González]]

Empezado por mamcx

En OSX/iOS es mas común que las app sean para usuarios finales, donde son trabajadas por startups, individuos o pequeñas empresas que se esfuerzan mas por hacer aplicaciones "soyadas". Eso es un punto que influye mucho en la calidad final.

Eso termina "pegandose". Y de pronto, es habitual esforzarse por tener un icono bueno, una tipografia buena, un esquema de colores decente, y preocuparse por cosas que antes no me preocupaban y que por los programas que veo a diario no preocupan mucho...

Captado el punto. Una cuestión de buenos hábitos, entonces.

[[Chris]]

Mucho fanatismo por Delphi en este hilo...

Hace como un año publiqué que dejaba oficialmente Delphi. Me dí cuenta que a pesar de ser una gran herramienta, no estaba a la talla para desarrollar aplicaciones Web (a lo que actualmente me estoy dedicando).

No sé, pero parecen olvidar que el desarrollo de aplicaciones de escritorio va en decadencia. Inclusive, desde el lanzamiento de W8 Delphi ya no es la mejor herramienta para desarrollar aplicaciones Windows. Quién no reconozca esto está ciego.

Tenemos que aceptar que Delphi, a pesar de ser una excelente herramienta para el desarrollo Win32, no es la mejor opción para las nuevas plataformas más populares y con mejores oportunidades de mercado. La soberbia es no querer ver y reconocer alternativas por meras preferencias personales.

Saludos!

[PepeLolo]

Un aporte a la discusión del responsable de una de las empresas más importantes en España en desarrollo de aplicaciones financieras.

[matabyte]

Yo he programado y programo actualmente para iPhone, Android, Aplicaciones win32, linux y mac. Hablo con experiencia de usar de todo, probar a programar en distintos sistemas, lenguajes y GUIs.

Delphi no es una maravilla, pero tampoco lo es el XCode, todos los lenguajes tienen sus cosas buenas y malas.

El precio del RAD Studio... yo tambien me quejo del alto precio, pero lo que no puedo tolerar es que los fanboys de XCode digan que es caro, porque si bien es pagar de una vez un gran precio, para programar para iPhone ocurre lo siguiente:
- Actualizacion a tu ultima version del iOS (porque si no no funcionara el nuevo XCode)
- Pagar por el developer certificate anualmente.
- Que no saquen una version del XCode nueva.
- Esto ya es impresión personal: El MAC no es precisamente barato comparado con un PC (con la diferencia puedes pagar tranquilamente un RAD Studio...).

Y que no me digan que programar para iPhone con el XCode es mas "simple" y bonito. A parte de necesitar la ultima versión del iOS y xCode (que habrás pagado para actualizar obligatoriamente), para instalar un programa que tu programas en tu iPhone necesitas conexion a internet y registrar tu iPhone con apple, sin hablar de los certificados necesarios solo para "testear" tu app (ni hablar de la publicacion en la app store y sus tiempos de review...).

Yo, sin perder el respeto por nadie (y nadie se me ofenda), veo a muchos moderadores del club delphi poner a parir a delphi... Si realmente odian y no les gusta el lenguaje y las herramientas que hay para programar (Lazarus, Rad studio, etc...) y no aportan como se podria mejorar y no animan para mejorar el producto y dar animos y recursos a los nuevos que se quieran iniciar (y seran los que desarrollen las herramientas de programacion del futuro), realmente para que estar es un foro de Delphi? no lo entiendo.

No se, este foro se llama club DELPHI por algo, si no se defendiera a Delphi, se deberia llamar "club programacion" o algo así.

Y como digo, sin animo de ofender a nadie.

PD: tengo un mal dia.