Aplikacja przenośna bez dostępu do sieci - wybór rozwiązania Opcje

[thek]

Ostatnio dziewczyna poprosiła mnie bym napisał aplikację. W pracy musi ona bowiem pewne rzeczy robić, a dostępne oprogramowanie nie obejmuje pewnych aspektów i to właśnie do nich miałbym napisać trochę kodu. Tutaj sprawa rozbiła się o zastosowanie technologii. Aplikacja ma być typu portable - wrzuta na pendrive. Dostęp do sieci internetowej - zero. Ma być dostępna baza danych relacyjna.
Z początku więc rozważałem sqlite jako plikową i polecono mi także Adobe Air. Z tego co doczytałem (nie znam AA) to jednak chcąc, nie chcąc musiałaby aplikacja i tak mieć jakieś połączenie z serwerem, który serwowałby jej obrabiane dane. Z tutoriali itp. odniosłem bowiem wrażenie, że integrować można HTML, JS, AS, tyle że mi to się zda psu na budę, skoro AS nie znam a muszę mieć logikę biznesową jakąś, bo niestety, ale przyjdzie w tym oprogramowaniu generować raporty itp. a same JS i HTML sobie w takim wypadku nie poradzą. Tutaj po prostu język skryptowy w stylu PHP jest niemal nieodzowny, bo gołych danych nie będę słał od razu do bazy bez walidacji i obróbki, a raportów JS też sobie sam nie wygeneruje.
Trochę popracowałem z google i stanęło na XAMMP lite (php + Apache + MySQL). Sprawdziłem i taka kombinacja działa na bank zgodnie z wymaganiami. Tylko czy da się coś innego zastosować? Może jakaś alternatywa dla mojego pomysłu? Nie chciałbym bowiem się do określonego jednego rozwiązania skłaniać "bo tak mi wygodnie". Może jest jakiś inny prosty "jednoklikowy" serwer Apache+MySQL (ew. sqlite mogę dać, bo to nie problem), bo wiecie jak to jest przy XAMPP... Z pena wejść tu, kliknąć tam, potem jeszcze parę kliknięć tu, a jeśli da się wejdź i kliknij tylko raz jeden plik który postawi wszystko to i wygoda większa (wiem... mogę walnąć bata, który uruchomi odpowiednie exe, ale a nuż jest jakiś jednoklikowy ).

[Puciek]

Wlasnie uzyles rozwiazan webowych do napisania aplikacji desktopowej, gratuluje.

[everth]

Ode mnie mogę polecić PyQt4 (wymaga Pythona) lub czyste Qt4 - wbudowane sqlite i (chyba) mysql embedded, super dokumentacja i dużo widżetów. Jak skompilujesz to statycznie jako binarkę C++ to właściwie niczego nie potrzebuje (poza windowsem)

[LBO]

Polecam Server2Go - używałem go do prezentacji - ale osobiście napisałbym to w Accessie.

Ten post edytował LBO 26.07.2010, 20:12:53

[nasty]

Ja pierd..
Po co tak na około jak można prościutko? wystarczy napisać aplikację desktopową a nie z pendrive odpalać serwer www, baze danych, przegladarke, i cala reszte zeby odpalić jakiś skrypcik.
C++, C#, VB, Java, Python, itd.. to wszystko umożliwia napisanie tego.

Ciekaw jak wyglądałby WinZip albo WinRar jakby jego autorzy tak podchodzili do sprawy

[destroyerr]

Tak swoją drogą, to czemu JS nie poradziłby sobie z raportami?
Moim zdaniem pomysł LBO z wykorzystaniem Accessa, jest kuszący, ale jak wiadomo zależy co dokładnie potrzebujesz.

[Puciek]

Ja pierd..
Po co tak na około jak można prościutko? wystarczy napisać aplikację desktopową a nie z pendrive odpalać serwer www, baze danych, przegladarke, i cala reszte zeby odpalić jakiś skrypcik.
C++, C#, VB, Java, Python, itd.. to wszystko umożliwia napisanie tego.

Ciekaw jak wyglądałby WinZip albo WinRar jakby jego autorzy tak podchodzili do sprawy

W php tez sie da napisac desktopowke jezeli jest odporny na wiedze

[everth]

Da się i w LOGO. Co nie znaczy że każdy jest masochistą

[thek]

To może tak dopiszę dla Pućka i innych pokpiewających Projekt nie wymaga ode mnie pośpiechu (pisać miałbym zacząć dopiero w październiku) i rozglądam się za rozwiązaniami. Z racji dość dużego kobiecego "rozrzutu wymagań"( ) myślę by robić to w wersji mającej 2 klientów, tak na wszelki wypadek. Dokładniej to pisałbym w miarę równolegle 2 aplikacje bazujące oczywiście na tej samej bazie danych. Gdyby chciała używać przeglądarki miałaby dostęp do klienta webowego (tutaj myślałem właśnie o wspomnianym rozwiązaniu czyli Apache+PHP+RDB), ale istniałby także klient desktopowy. Co do tego drugiego to jakoś Java nigdy mi nie podchodziła, więc bardziej skłonny jestem użyć którejś z graficznych bibliotek C++, bo pisać samemu GUI w C++ to masochizm. A C++ zawsze lubiłem jako język, co bardziej do mnie przemawia i skłaniałbym się do Qt, ale że mało graficznych aplikacji pisałem i już kilka lat temu, więc nie orientuję się bardzo jak zmieniła wygoda jego użytkowania (to, że licencja się zmieniła to wiem). Z tego co doczytałem, istnieje także obsługa PHP w nim w formie projektu PHPQt, co dodatkowo byłoby fajne, gdyż zapewne (nie wiem, nie wczytałem się jeszcze w dokumentację PHPQt) różnica między desktopem i webową wersją ograniczyła by się do zaprojektowania innych widoków, GUI dla nich. Z racji jednak długiego czasu na przemyślenie (2 miesiące) mogę poczytać o ewentualnie innych rozwiązaniach, propozycjach.

[batman]

Jeśli chcesz pisać aplikację desktopową, która ma działać na Windows, proponuję C#. Jeśli aplikacja nie będzie zbyt skomplikowana, to przy odrobinie wysiłku napiszesz ją w kilka tygodni. Co do bazy danych, to dużo Ci nie pomogę, niestety nie zagłębiałem się w obsługę baz danych w aplikacjach desktopowych, jednak nie powinieneś mieć problemu z zastosowaniem SQL Server w swoim projekcie (poczytaj o wersji Compact). Na upartego możesz zrobić aplikację w Silverlight, która instaluje się w systemie i nie wymaga przeglądarki internetowej.

Dlaczego skreśliłeś Adobe AIR? Możliwości oferowane przez wersję z obsługą Javascript są na prawdę duże i niewiele ustępują Action Script. Z drugiej jednak strony AS3 jest bardzo prosty do nauki i nie straciłbyś dużo czasu na naukę. Musiałbyś tylko przestawić się na programowanie oparte o zdarzenia, co wielu osobom sprawia problemy.

[emp]

darmowe multi-platformowe gui dla c++ http://www.wxwidgets.org/ i darmowy wizualny edytor http://wxdsgn.sourceforge.net/ w tym możesz napisać swoją aplikację desktopową, dość szybko i sprawnie skoro java ci nie odpowiada. Zamiast bazy zastosowałbym zwykła serjalizację do pliku dla jednego użytkownika i aplikacji desktopowej.

Ten post edytował emp 27.07.2010, 08:37:38

[athabus]

A ja przekornie zostałbym przy pierwotnym założeniu - tj. aplikacji webowej. Nie jest to optymalne rozwiązanie, ale idę o zakład, że napiszesz szybciej tą aplikację w znanych Ci technologiach niż nauczysz się czegoś nowego. Wiadomo jakie potworki wychodzą z pierwszych próba programowania w danym języku/środowisku ;-)

Także jeśli jedynym celem jest napisanie tej aplikacji to napisałbym ją w narzędziu, które znam nawet jeśli nie jest ono optymalne do tego celu.

[SHiP]

Popieram athabusa. Choć z drugiej strony nauczyłbyś się czegoś nowego.

Co do PHP-Qt - huh.. można się rozczarować . Nie ma np. slotów i sygnałów. W sumie, nie chodzi o to, że pomysł jest nieciekawy(bo może się to przydać w przyszłosci) ale bardzo mało osbób w ogóle się tym interesuje więc społeczność jest mała.

Ze zwykłych języków mógłbym polecić C++ jednak różnice w obiektówce w porównaniu do PHP/Javy są ogromne(głównie chodzi mi o wiązanie ale nie tylko) i mogłoby to być męczące jeśli nie pisałeś dużo w c++.

[Fifi209]

Sam przygodę z programowaniem zaczynałem od C++, szybko porzuciłem go na rzecz PHP i JS.
Po pewnym czasie zainteresowałem się Javą, lecz w żaden sposób nie przemawiał do mnie ten język. Spróbowałem C# i przez kilka tygodni tylko w nim pisałem, olałem php i resztę. ;p Nie wiem właściwie czemu ten język mi się tak spodobał. Przyzwyczajony jestem do prostych języków typu php a tutaj taka zamiana, w dodatku tam jest obiektowe wszystko (Chyba), ale bardzo przyjemnie się w nim pisze.

Osobiście polecałbym C# jeżeli platformą ma być Windows, w przeciwnym wypadku (różne platformy) pozostaje tylko Java.

Z tymi językami jest o tyle problem, że C# wymaga .NET z tego co pamiętam, z resztą Java też potrzebuje środowiska w którym się uruchomi.

PHP? Do takiej aplikacji raczej w żaden sposób się nie nada. ;p
C++? Lubisz? Jesteś masochistą? Ma to swoje plusy, kod wykonuje się bardzo szybko.

[athabus]

fifi - c# to bardzo fajny język, zwłaszcza w połączeniu z ide od ms. Piszę się na prawdę szybko i łatwo, dlatego też taka moda teraz na niego. Sam gdybym miał coś pisać na desktopy to pewnie kierowałbym się w jego stronę.

C++ i C# nie ma co porównywać bo to trochę inne języki/zastosowania.

Natomiast co do tego, że php nie nadaje się na aplikacje desktopowe to hmm. Kiedyś też bym tak stwierdził, ale ostatnio coraz bardziej się nad tym zastanawiam. Pracuje w wolnych chwilach nad takim projektem backendu do sklepu internetowego, który zawiera:
- prosty system magazynowy z wprowadzaniem zakupów etc
- integrację z działającym sklepem - pobieranie zamówień etc
- wyszukiwanie towarów
- sprawdzanie kompletności zamówień (skaner kodów kreskowych porównuje co jest w koszyku z faktycznym zamówieniem)
- wprowadzanie faktur zakupowych
- planuje też dodać obsługę kasy fiskalnej bo podobno jest to możliwe
- wykonywanie zamówień w hurtowniach
- planowanie tras dla kurierów (tu np. zastosowałem taki fajny myk z drag&drop)

Wszystko to napisane jest w php (a dokładniej w symfony) + jquery do interfejsu. Dzięki dużej ilości jquery i ajaxu wszystko działa bardzo fajnie - interfejs w moim odczuciu w ogóle nie ustępuje pod względem wygody takiemu jaki oferują aplikacje okienkowe - mam wszystkie rzeczy takie jak: drag&drop, pola tekstowe z autocomplete, itd. Można mówić, że nie jest to technologia przeznaczona do tego typu rzeczy i z tym się zgodzę, ale przy dobrym przemyśleniu tematu spokojnie można odtworzyć w przeglądarce wszystko to co ma aplikacja desktopowa.

Wg mnie w ogóle oprogramowanie będzie trochę ewoluowało w takim kierunku (pewnie powstaną nowe technologie albo frameworki rad'owe do istniejących rozwiązań), bo programy oparte o webowe technologie mają trochę plusów np:
- brak konieczności instalacji
- praktycznie 100% przenośności między systemami

Dzięki temu np. mogę odpalić system magazynowy na iphonie gdy akurat nie ma mnie w biurze a chce coś sprawdzić.

Nie chciałbym zostać źle zrozumiany - nie uważam, że programowanie aplikacji desktopowych za pomocą technologii webowych jest najlepszym rozwiązaniem, ale jak najbardziej jest to możliwe bez utraty funkcjonalności, a nawet ma to pewne swoje plusy.Co do szybkości pisania to (sam się zdziwiłem) przy zastosowaniu frameworków (ja stosowałem symfony i jquery) wcale nie ma aż tak dużej różnicy w porównaniu z np. C#.

[Fifi209]

Wg mnie w ogóle oprogramowanie będzie trochę ewoluowało w takim kierunku (pewnie powstaną nowe technologie albo frameworki rad'owe do istniejących rozwiązań), bo programy oparte o webowe technologie mają trochę plusów np:
- brak konieczności instalacji
- praktycznie 100% przenośności między systemami

Dzięki temu np. mogę odpalić system magazynowy na iphonie gdy akurat nie ma mnie w biurze a chce coś sprawdzić.

Nie chciałbym zostać źle zrozumiany - nie uważam, że programowanie aplikacji desktopowych za pomocą technologii webowych jest najlepszym rozwiązaniem, ale jak najbardziej jest to możliwe bez utraty funkcjonalności, a nawet ma to pewne swoje plusy.Co do szybkości pisania to (sam się zdziwiłem) przy zastosowaniu frameworków (ja stosowałem symfony i jquery) wcale nie ma aż tak dużej różnicy w porównaniu z np. C#.

Co do przenośności nie zgodzę się w 100%, jak widzisz potrzeba odpalić serwer apache - to minimalne wymaganie. I po zabawie z iPhonem.

[athabus]

Halo, ale to jest akurat specyfika problemu theka, że musi odpalić to na komputerze bez internetu. W normalnych warunkach stawiasz przecież serwer i na nim odpalasz aplikację. Klient potrzebuje tylko przeglądarki ;-) Mój system magazynowy będzie stał na komputerze w firmie (w celu zwiększenia responsywności) + poprzez zewnętrzne ip będzie dostępny z dowolnego miejsca, tak aby można było coś "sprawdzić na szybko" np. za pomocą iphona.

Zauważ, że pojawia się coraz więcej aplikacji, które kiedyś stały na desktopach a teraz migrują do sieci właśnie ze względu na wygodę użytkowania/możliwość korzystania z kilku komputerów czy telefonów. Np. projekty tupu menadżery osobiste, listy zadań, kalendarze, aplikacje do przechowywania zdjęć, systemy do księgowości i wiele innych. Czasami pisze się też dwa frontendy - jeden desktopowy aby można było korzystać z aplikacji na co dzień i drugi webowy, który realizuje jakieś wybrane operacje - np. wsparcie dla mobilnych pracowników. Np. jedna z obsługujących mnie hurtowni ma przedstawicieli, którzy składają zamówienie poprzez przeglądarkę.

Ja osobiście wierzę, że jest to trend, który będzie się wzmacniał - pytanie tylko jaka technologia zostania dostosowana do pisania tego typu aplikacji - php ma wszystko czego potrzeba gdy połączysz to z javascriptem. Brakuje tylko jakiegoś ide typu rad, który zintegrowałby wszystkie technologie w jedno narzędzie.

Sam napisałem swój system z prozaicznej przyczyny - na rynku nie było nic co sprostałoby moim skromnym ale wyszukanym oczekiwaniom (no może poza systemami za >100k zł), a nie czułem się na tyle dobry w rzeczach desktopowych aby pisać w nich tak skomplikowany system. Ogólnie jednak mogę powiedzieć, że udało mi się odtworzyć w przeglądarce wszystko czego potrzebuje aplikacja do zastosowań biurowych bez utraty funkcjonalności (a nawet doszło kilka zalet) i przy tym wcale nie było to takie trudne jakby mogło się wydawać. Sam znam JavaScript bardzo słabo, ale dzięki jQuery interfejs nie stanowi już problemu nawet dla osoby używającej JS od święta.

[darko]

Halo, ale to jest akurat specyfika problemu theka, że musi odpalić to na komputerze bez internetu. W normalnych warunkach stawiasz przecież serwer i na nim odpalasz aplikację. Klient potrzebuje tylko przeglądarki ;-) Mój system magazynowy będzie stał na komputerze w firmie (w celu zwiększenia responsywności) + poprzez zewnętrzne ip będzie dostępny z dowolnego miejsca, tak aby można było coś "sprawdzić na szybko" np. za pomocą iphona.

Zauważ, że pojawia się coraz więcej aplikacji, które kiedyś stały na desktopach a teraz migrują do sieci właśnie ze względu na wygodę użytkowania/możliwość korzystania z kilku komputerów czy telefonów. Np. projekty tupu menadżery osobiste, listy zadań, kalendarze, aplikacje do przechowywania zdjęć, systemy do księgowości i wiele innych. Czasami pisze się też dwa frontendy - jeden desktopowy aby można było korzystać z aplikacji na co dzień i drugi webowy, który realizuje jakieś wybrane operacje - np. wsparcie dla mobilnych pracowników. Np. jedna z obsługujących mnie hurtowni ma przedstawicieli, którzy składają zamówienie poprzez przeglądarkę.

Ja osobiście wierzę, że jest to trend, który będzie się wzmacniał - pytanie tylko jaka technologia zostania dostosowana do pisania tego typu aplikacji - php ma wszystko czego potrzeba gdy połączysz to z javascriptem. Brakuje tylko jakiegoś ide typu rad, który zintegrowałby wszystkie technologie w jedno narzędzie.

Sam napisałem swój system z prozaicznej przyczyny - na rynku nie było nic co sprostałoby moim skromnym ale wyszukanym oczekiwaniom (no może poza systemami za >100k zł), a nie czułem się na tyle dobry w rzeczach desktopowych aby pisać w nich tak skomplikowany system. Ogólnie jednak mogę powiedzieć, że udało mi się odtworzyć w przeglądarce wszystko czego potrzebuje aplikacja do zastosowań biurowych bez utraty funkcjonalności (a nawet doszło kilka zalet) i przy tym wcale nie było to takie trudne jakby mogło się wydawać. Sam znam JavaScript bardzo słabo, ale dzięki jQuery interfejs nie stanowi już problemu nawet dla osoby używającej JS od święta.

Amen. Dodam od siebie, że niektóre javascriptowe frameworki np. ExtJS oferują niemalże większość (jeśli nie wszystkie + nawet to, czego desktopy nie oferują lub oferują bardzo rzadko) dostępnych kontrolek desktopowych (edytowalne listy, drzewa, ) i generalny trend jest taki, że zarówno wygląd, jak i funkcjonalność poszczególnych elementów składowych aplikacji internetowych zmierzają do maksymalnego zbliżenia do tego, co oferują aplikacje desktopowe. Zresztą, co tu dużo pisać, wystarczy wejść na przykład tutaj - proszę kompletny desktop (symulacja pulpitu).

[thek]

No to po kolei
@batman: aplikacja znając życie nie wyjdzie poza środowisko windowsa, więc c# ma szanse. Co do bazy danych z racji przenośności skłaniałbym się ku sqlite, ale postawić chodzący w tle serwer mysql nie jest trudno. W zasadzie napisałem już dziewczynie skrypt batowy, który odpala jednym kliknięciem apache, mysql i uruchamia portable firefox. Tak więc środowisko użytkowe miałaby w pełni przygotowane. AdobeAir skreśliłem z racji tego, że muszę dane walidować, obrabiać, tworzyć raporty i obawiam się, że sam AA by nie dał rady. Skoro musi się wspierać dodatkowym skryptem który mu dane przygotuje choćby do formy JSON, to już lepiej całość w PHP zrobić z pominięciem tej technologii. AA daje mi tylko uniezależnienie od przeglądarki tak naprawdę w tym wypadku jedynie. Jeśli C# wymaga .NET do działania to trochę mniej ciekawie się to zapowiada, bo nie wiem czy jest ona zainstalowana na kompach. To samo tyczy JVM w przypadku Javy i stąd właśnie te 2 języki daje na listę rezerwowych.
@emp: o wxwidgets też myślałem... Ba mam nawet książkę w domu o pisaniu pod qt i wxwidgets aplikacji z GUI, więc też nad tym myślę czy nie byłoby sięgnąć i nie zgłębić tematu lepiej. Co do serializacji to boję się o wydajność tego rozwiązania, ale są to obawy, które mógłbym skonfrontować z sqlite i mysql ostatecznie.
@athabus: miałem długi kontakt z C++ (także STL), więc to nie jest skok na głęboką wodę. A co do PHP to faktycznie wiele osob myśli php = webdeveloping, co akurat jest jak dla mnie zbytnim uproszczeniem. Wywodzi się on bowiem z C i tak jak on nie ma po prostu własnych bibliotek stricte GUI niemal od początku (qt i inne biblioteki gui to dopiero późniejsze pomysły) jak choćby Java i jej awt oraz późniejszy swing.
@SHiP: Akurat C++ się nie boję. Jak wspomniałem już kiedyś parę razy, do PHP podchodziłem z bagażem z C++ właśnie i php uznałem za taki mocno okrojony C bez wielu rzeczy znanych mi z C oraz kilkoma uproszczeniami jak brak typizacji choćby czy wielodziedziczenia i polimorfizmu. Jeśli faktycznie Php-Qt nie jest taki fajny to może rzeczywiście na samym Qt gołym bym się skupił jeśli na niego ostatecznie padnie wybór.
@fifi209: C++ nie jest obiektowy. Podobnie jak php jest obiektowo orientowany. Możesz pisać cały kod strukturalnie jeśli chcesz. Twoja wola i pomysł A co do iPhone'a to myślisz, że na MacOSX nie dałoby się odpalić jakiegoś prostego serwerka z obsługą php? Myślę, że jak najbardziej tak Poza tym to aplikacja w sumie CRUD więc coś co najczęściej właśnie php od strony webowej robi i dlatego ten język jak najbardziej tu pasuje logicznie. A co do przenośności to Athabus ma rację. Jest przenośne jeśli masz połączenie z netem. Wtedy tylko łączysz z serwerem, który przesyła całość GUI. Problemy mogą być jedynie z komórkami, które JS nie wspierają.

Jak na razie więc byłoby:
Baza danych: sqlite, mysql (konieczne postawienie serwera) bądź serializacja do pliku
Klient webowy: php+JS+CSS (ogólnie standard z koniecznością postawienia serwera Apache'a)
Klient desktopowy: na razie pierwsze miejsce idzie ku C++ z biblioteką Qt jako GUI, dalej wxWidgets i rezerwa C#

[everth]

Jeśli mimo wszystko zdecydowałbyś się na jakiś język interpretowany to przemyśl kilka razy Pythona (do gui np. PyQt4 lub inne bindy - PyGtk). Niesamowicie wygodny obiektowy język. Z mojego punktu widzenia wymusza chyba najczytelniejszy układ kodu (wcięcia). W dodatku jak osiądziesz w Pythonie to możesz później przeskoczyć na jego webowe frameworki (np. Django). Nie jest on tak popularny jak PHP-owe frameworki, ale ostatnio konkurencja na tym polu jest duża