Может ли это работать - пользовательский интерфейс Objective-C, предоставляемый серверной частью Java, упакованной в одно приложение Mac для настольных компьютеров? - PullRequest
2 голосов
/ 13 марта 2012

Профессионально, я бэкэнд-разработчик Java, но недавно я заинтересовался написанием настольного приложения для Mac и в результате начал изучать Objective-C. Моя проблема в том, что чем больше я углубляюсь в сложности Objective-C, тем больше мне хотелось бы, чтобы я просто писал свое приложение на Java, особенно для того, чтобы использовать множество фреймворков и т. Д., Которые может предложить Java.

Итак, мой вопрос заключается в следующем: может ли кто-нибудь дать мне (убедительную!) Причину не разрабатывать мой новый проект на стороне Java и пользовательский интерфейс в Objective-C? По сути, я прошу кого-нибудь выстрелить в меня из воды, скажите мне, что я дурак, что даже рассматриваю это!

Каковы недостатки этого подхода? Производительность, которую я представляю, будет иметь первостепенное значение, но в моем опыте работы с Java бэкэнд имеет тенденцию приближаться к производительности собственного кода (если он написан хорошо). Может ли этот подход даже работать? Возможно, с какой-нибудь причудливой структурой обмена сообщениями (json?), Перекачивающей данные между сторонами Java и Objective-C?

Пит

Ответы [ 4 ]

2 голосов
/ 13 марта 2012

Если у вас большой объем существующего Java-кода, то это выполнимый план.Связь между пользовательским интерфейсом и внутренним интерфейсом может быть выполнена с помощью собственного интерфейса Java , чтобы блокировать вызовы объектов / методов туда и обратно, вместо того, чтобы разрабатывать и реализовывать сетевой протокол.

Однако имейте в виду, что Java не поставляется с последними версиями Mac OS X (пользователям будет предложено загрузить и установить его), и приложения, включающие компоненты Java, не будут приняты в Mac App Store.

0 голосов
/ 28 ноября 2015

Вы можете решить, хотите ли вы поставлять много разных устройств, таких как iphone, планшеты, android, windows phone и т. Д. Было бы неплохо, если бы вам не приходилось многократно копировать и вставлять один и тот же код.раз.То же самое можно использовать на веб-сайте.

Этот подход также можно использовать, если у вас есть межфункциональная команда.Я имею в виду команду для поддержки серверной части, другой интерфейс для телефонов, другой интерфейс для веб-сайта и т. Д.

Это более гибкий подход, и я предпочитаю его.Но это может быть то, что подходит вам лучше, если вы пройдете через бэкэнд, и задача-с займет больше времени, чем все на цели-с.По объективному подходу c хорош в краткосрочной перспективе, но в долгосрочной перспективе бэкэнд, который заботится о данных, будет выгоден!

0 голосов
/ 13 марта 2012

Проблема с JNI в этом случае заключается в том, что вы можете вызывать код C или C ++ из java, но я не уверен, что так просто вызвать обратный вызов. Здесь требование заключается в том, что пользовательский интерфейс Objective C должен вызывать бэкэнд-программу Java. Мне также любопытно, что это можно сделать с помощью JNI?

С уважением, Рахул

0 голосов
/ 13 марта 2012

Этот подход позволяет работать с помощью сокетов. Ваши программы target-c будут отправлять запрос в формате JSON или в любом другом формате для бэкенда java на конкретном сокете и продолжать слушать на конкретном сокете, то, что будет делать java-программа, это прослушивать общий сокет, получать этот запрос и создавать требуемый ответ и отправлять обратно на прослушивающий сокет. Я не смогу дать никакого исходного кода для этого до тех пор, пока я не пойму ваше требование подробно.

С уважением, Рахул

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...