Qual idioma devo usar para criar uma biblioteca de plataforma cruzada? [fechadas]


10

Eu quero criar uma biblioteca de análise SyncML ( sem interface do usuário ) que possa criar mensagens com base nas informações fornecidas pelo aplicativo host, alimentadas pelos métodos da biblioteca. Além disso, a biblioteca deve poder fazer retornos de chamada para métodos no aplicativo host.

Quero poder compilar isso e disponibilizá-lo no maior número possível de plataformas: Windows, SO Windows Phone 7, OSX, iOS, Linux, Android, BlackBerry. Basicamente, tantas plataformas quanto possível.

A prioridade é disponibilizá-lo em dispositivos móveis.

Questões:

  1. Que configuração devo usar? (linguagens de programação, compiladores, IDE etc.)
  2. Como eu compilaria essa biblioteca para essas diferentes plataformas e como eu me conectaria a ela?
  3. Alguma outra informação? por exemplo, artigos que abordam o assunto de desenvolvimento de plataforma cruzada?

Eu não fiz esse tipo de projeto de plataforma cruzada antes, portanto qualquer informação disponível para me colocar na direção certa seria bem-vinda.

Eu mesmo, tenho experiência em C # / .NET e Objective-C.

Respostas:


8

Usar a plataforma Java / JVM seria a escolha óbvia - ele possui a cobertura mais ampla de qualquer idioma e, se você tiver um background em C # / .net, os conceitos serão muito familiares.

Observe que você não precisa usar a linguagem Java para obter os benefícios da plataforma Java - na verdade hoje em dia, se iniciar um projeto do zero, provavelmente recomendo um dos seguintes:

  • Scala - se você deseja um idioma poderoso, de tipo estatístico e com vários paradigmas, com excelente desempenho na JVM. Poderia atender você se você tiver um plano de fundo em C #.
  • Clojure - se você prefere programação funcional, como linguagens dinâmicas e gosta de viver na vanguarda. O Clojure possui recursos de simultaneidade realmente excelentes, que podem ser atraentes - vale a pena assistir ao vídeo vinculado para obter algumas informações detalhadas.
  • Groovy - se você deseja uma linguagem de script orientada a objetos dinâmica simples, mas eficaz, que seja familiar aos desenvolvedores de C # / Java.

Todas essas linguagens têm todos os benefícios de estar na JVM (compilador JIT fantástico, coleta de lixo muito eficaz, um enorme conjunto de bibliotecas), mas são linguagens muito mais produtivas para trabalhar.

A propósito, já existe uma biblioteca SyncML de código aberto disponível em Java chamada Funambol . Não tenho certeza da extensão em que isso é útil diretamente para você, mas é um exemplo do fato de que geralmente existe uma biblioteca Java de código aberto para praticamente qualquer coisa .......

Pensamentos sobre outras opções:

  • O C / C ++ certamente pode funcionar em várias plataformas, mas requer uma recompilação (e teste subsequente) no código nativo para cada plataforma. Com as linguagens da JVM, isso não é necessário, pois o próprio bytecode compilado é portátil. A menos que você precise absolutamente de C / C ++ para desempenho ou acesso a recursos brutos de hardware, acho que é uma dor de cabeça que você deve evitar.
  • O C # na forma de Mono poderia funcionar (testemunhar o sucesso do Unity como uma biblioteca de plataforma cruzada, por exemplo), mas não é o lugar do ecossistema da JVM em termos de maturidade, disponibilidade da biblioteca ou mesmo desempenho bruto. Além disso, nunca será 100% compatível com o Microsoft .Net, já que o .Net possui recursos específicos do Windows, que são um pesadelo para a portabilidade. Ainda assim, vale a pena considerar se você está determinado a seguir o C #.
  • Javascript pode ser uma opção externa se você estiver interessado em usar a biblioteca no lado do cliente e do servidor.

11
Obrigado pela ótima resposta. Você sabe o quão bem é possível portar Java para o iPhone, na forma de uma biblioteca ou estrutura? Além disso, não posso usar o Funambol, o objetivo é criar minha própria biblioteca.
Andrei

2
Eu entendo que a Apple está sendo bastante restritiva sobre Java no iPhone atualmente. Espero que a pressão do mercado faça com que isso aconteça mais no futuro - este artigo theserverside.com/discussions/thread.tss?thread_id=63072, por exemplo, fala sobre a Oracle demonstrar um aplicativo baseado em Java no iPod Touch.
Mikera

+1 por me informar sobre a não necessidade de usar Java por si só, mas pode-se usar Scala, Clojure, Groovy. Resposta fascinante.
Anthony

3

Você pode experimentar o Java - o Java Runtime Environment (a máquina virtual) é multiplataforma, o Java pode ser usado em dispositivos móveis com Android (ou Java ME) e o .NET é muito parecido com ele.


3

Esta não é uma escolha, mas muitas. Embora seja tentador encontrar uma coisa que vá a todos os lugares, nem sempre é a melhor maneira de fazer.

  1. Por exemplo, embora seja possível espremer um código C ++ na plataforma móvel Windows, qualquer coisa que o .NET sempre seja mais fácil aqui do que sua contrapartida do ponto de vista do suporte.

  2. Da mesma forma, é necessário fazer uma escolha importante, quer você queira que seja nativo ou em tempo de execução, e você está estritamente limitado a um poderoso centrado na Web ou mais genérico? Por exemplo, o Adobe Runtime é mais onipresente, mas limitará o que você pode fazer em comparação com as principais linguagens de programação.

  3. O mais importante, eu acho, é o tipo e o nível da GUI que você deseja criar.

Agora vamos às escolhas mais promissoras.

uma. Para Symbian, Blackberry, Android, BREW e Bada (samsung), Java / J2ME é a maneira mais comum. Porém, em muitos casos, você pode ser melhor com o C / C ++, para itens principais nativos em alguma plataforma.

b. Para o Windows .NET com qualquer idioma suportado, seria bom.

c. Para iOS - não há escolha a não ser o objetivo C. Isso não é muito C ++, então não vou contá-lo como objetivo

Aqui está uma referência wiki que mostra o conjunto de todas as plataformas que mostra todas as opções e onde elas se aplicam.

Graças à sua pergunta, aprendi no link wiki acima que agora existem SDKs que tentam resolver o problema acima. Os dois que mais se aproximam são:

  1. Marmalade: http://www.madewithmarmalade.com/marmalade/supported-platforms isto oferece suporte interessante a quase todas as plataformas. O Windows está prestes a ser adicionado para fazer um círculo completo.

  2. Código de partículas: http://www.particlecode.com/

Ainda não os usei, mas soa um trabalho interessante.


O Android fornece Bada e o iOS permite C ++.
Klaim

3

O .NET dificilmente está disponível em muitas plataformas, e o Objective-C é ainda pior, mais o .NET é meio lento e o ObjC basicamente não tem suporte fora da Apple. C como idioma não vale a pena considerar, a menos que algum fator externo faça você usá-lo.

A única linguagem viável para o resultado é o C ++.


2
Você sabe alguma coisa sobre as vantagens de usar o projeto Mono em combinação com C #? Por que não vale a pena considerar C?
Andrei

2
@Andrei: Até onde eu sei, Mono dificilmente é a imagem da disponibilidade em todas as plataformas que você listou. E não vale a pena considerar C porque é como C ++, mas com todos os bons recursos cortados, o que é obviamente uma coisa estúpida a ser feita se você pode usar C ++.
DeadMG

4
@DeadMG: Eu adoraria ver você debater esse ponto com Linus Torvalds: thread.gmane.org/gmane.comp.version-control.git/57643/… - sem dizer que ele deve estar 100% certo, eu apenas gosto de assistir a guerra de chamas.
precisa

2
O @DeadMG C não é C ++ com os bons recursos cortados; C ++ é C com recursos horríveis adicionados. Não há nada errado com C.
rightfold

2
@WTP: Ele pediu uma recomendação, não a minha história de vida. O fato simples é que, o que você acha dos recursos extras do C ++, o fato é que eles existem e tornam o código C ++ - apenas acessível, o que é um bônus, e C não é nada que o C ++ não seja - o contrário não é verdade. Quando você usa C ++ sobre C, você adiciona apenas opções. Portanto, por definição, o C ++ é uma linguagem superior e você sempre pode optar por não usar os recursos do C ++. O que seria loucura, mas você pode.
DeadMG
Ao utilizar nosso site, você reconhece que leu e compreendeu nossa Política de Cookies e nossa Política de Privacidade.
Licensed under cc by-sa 3.0 with attribution required.