Czy jest na sali ktos kto juz bawil sie z tym i moze mi wyjasnic czarna magie jaka mi zaserwowal MicroSoft?
0
0
A co konkretnie ci potrzeba? Poza brakiem wsparcia dla Win10M nie widzę jakichś super wielkich różnic pomiędzy UWP w VS2017 i 2019.
0
Kolego gdzie ja znajde jakies poradniki na temat debugowania aplikacji w VS pod architekture ARM? Mam telefon Nokia Lumia z WIndowsem 10. Wczoraj jakims cudem udalo mi sie polaczyc w przegladarce z telefonem po adresie IP i pozniej po jakims czasie Windows na PC sie obrazil i nie chce juz wiecej laczyc sie z urzadzeniem przy uzyciu Device Portal. Jak ja mam pracowac w takich warunkach? W VS 2015 byl emulator i bylo mniej problemow bo aplikacja od razu byla uruchamiana a w VS 2019 to juz jest jakis dramat. Z tego co rozumiem to iz jeli chcemy wydac aplikacje UWP to musimy posiadac dane urzadzenie fizycznie? Jak wy sobie pracujecie przy aplikacjach na np telefony z Windowsem 10?
0
Ktos napisał(a):
A co konkretnie ci potrzeba? Poza brakiem wsparcia dla Win10M nie widzę jakichś super wielkich różnic pomiędzy UWP w VS2017 i 2019.
Przy probie debugowania wyskakuje blad: > Failed to connect to device '127.0.0.1' using Universal Authentication.
Nie wiem co jest nie tak. Bo nigdzie nie widze poradnikow na temat urzadzen z ARM. Juz 2 dni spedzilem aby cos sie dowiedziec i nic.
0
Jest sukces. Udalo mi sie uruchomic aplikacje i dziala. Jeszcze pozostala kwestia braku polaczenia poprzez IP z komputera.
1
Visual Studio 2019 nie obsługuje deployowania (i testowania) aplikacji dla Windows 10 Mobile: https://docs.microsoft.com/pl-pl/visualstudio/releases/2019/compatibility, a w szczególności https://developercommunity.visualstudio.com/content/problem/458381/dep6711-deployment-to-windows-mobile-is-no-longer.html. Wynika to m.in. z faktu, że W10M traci wsparcie 10 grudnia 2019.
Musisz używać 2017, jeżeli chcesz budować aplikacje dla Windows 10 Mobile, używając SDK w wersji nie nowszej niż 15063 (Creators Update) (w zasadzie wyszło Windows 10 Mobile Fall Creators Update, ale nie osiągnęło wersji 16299, tylko nieco mniejszą).
W VS 2015 byl emulator i bylo mniej problemow bo aplikacja od razu byla uruchamiana a w VS 2019 to juz jest jakis dramat. Z tego co rozumiem to iz jeli chcemy wydac aplikacje UWP to musimy posiadac dane urzadzenie fizycznie?
W 2017 też był emulator, w 2019 nie ma, z powodu, który napisałem wyżej. Aczkolwiek i tak trzeba było w pewnym momencie testować na urządzeniu fizycznym (albo zawsze, zależy od aplikacji).
Jak wy sobie pracujecie przy aplikacjach na np telefony z Windowsem 10?
Już nie pracujemy, bo Microsoft się wypiął na nas :)
0
Ktos napisał(a):
Już nie pracujemy, bo Microsoft się wypiął na nas :)
Czyli co teraz pozostaje? Android SDK? Czy latwiej sie pracuje na Androidzie i czy tam mozna tez pracowac bezposrednio np Device -> SQL -> Device. Widze ze kolego masz duza wiedze o urzadzeniach mobilnych. Moim celem jest zrobic aplikacje pod stare telefony tak aby wykorzystac potencjal szrotow. Masz w tym kierunku jakies sugestie?
0
Czyli co teraz pozostaje? Android SDK? Czy latwiej sie pracuje na Androidzie
Nie wiem czy łatwiej, według mnie nie, ale ja jestem przyzwyczajony do określonych rozwiązań ;)
Możesz spojrzeć na Xamarina, w którym możesz budować aplikacje w C# dla Androida, iOS i Windows albo UNO w którym możesz swoją aplikację UWP przenieść na Androida, iOS i WebAssembly. O ile mówimy o C#, bo jeśli go nie potrzebujesz/nie chcesz to i tak to nie ma znaczenia :)
i czy tam mozna tez pracowac bezposrednio np Device -> SQL -> Device.
Ogólnie - sugestia jest taka, żebyś tego nie robił. Zrób sobie jakieś API, na przykład w postaci aplikacji webowej, która będzie odbierać dane od twoich urządzeń jakimś uniwersalnym protokołem (np. MQTT albo HTTP) i to ona będzie trzymać dane w bazie danych i przesyłać je dalej również jakimś uniwersalnym sposobem. Wtedy nieważne czy tworzysz aplikację dla Androida, Windows, Windows Phone, czy dla jakiegoś niskomocowego układu typu ESP8266 - i tak będą w stanie się dogadać.
Przykładowo, mam projekt, w którym: urządzenia ESP8266, przesyłają dane do Raspberry Pi, na którym działa broker MQTT, jak również aplikacja webowa (ta odbiera po HTTP). Aplikacja webowa zapisuje dane do bazy danych (i generuje wykresy i inne takie). Dane z części webowej odbiera aplikacja UWP dla Windows 10 i pokazuje je na bieżąco. Jest też aplikacja dla Windows 10 Mobile (i kiedyś była też dla Windows Phone 8), która robi mniej więcej to samo i jest też aplikacja dla Androida, która robi mniej więcej to samo. Dzięki użyciu MQTT i HTTP nieważne jaką mam platformę, wszystko jest w stanie się ze sobą dogadać. A jak kiedyś zmienię MySQL na PostgreSQL to też nie będę musiał zmieniać wszystkiego, a tylko część webową - bo tylko ona dotyka MySQL.
0
Ktos napisał(a):
Czyli co teraz pozostaje? Android SDK? Czy latwiej sie pracuje na Androidzie
Nie wiem czy łatwiej, według mnie nie, ale ja jestem przyzwyczajony do określonych rozwiązań ;)
Możesz spojrzeć na Xamarina, w którym możesz budować aplikacje w C# dla Androida, iOS i Windows albo UNO w którym możesz swoją aplikację UWP przenieść na Androida, iOS i WebAssembly. O ile mówimy o C#, bo jeśli go nie potrzebujesz/nie chcesz to i tak to nie ma znaczenia :)
i czy tam mozna tez pracowac bezposrednio np Device -> SQL -> Device.
Ogólnie - sugestia jest taka, żebyś tego nie robił. Zrób sobie jakieś API, na przykład w postaci aplikacji webowej, która będzie odbierać dane od twoich urządzeń jakimś uniwersalnym protokołem (np. MQTT albo HTTP) i to ona będzie trzymać dane w bazie danych i przesyłać je dalej również jakimś uniwersalnym sposobem. Wtedy nieważne czy tworzysz aplikację dla Androida, Windows, Windows Phone, czy dla jakiegoś niskomocowego układu typu ESP8266 - i tak będą w stanie się dogadać.
Przykładowo, mam projekt, w którym: urządzenia ESP8266, przesyłają dane do Raspberry Pi, na którym działa broker MQTT, jak również aplikacja webowa (ta odbiera po HTTP). Aplikacja webowa zapisuje dane do bazy danych (i generuje wykresy i inne takie). Dane z części webowej odbiera aplikacja UWP dla Windows 10 i pokazuje je na bieżąco. Jest też aplikacja dla Windows 10 Mobile (i kiedyś była też dla Windows Phone 8), która robi mniej więcej to samo i jest też aplikacja dla Androida, która robi mniej więcej to samo. Dzięki użyciu MQTT i HTTP nieważne jaką mam platformę, wszystko jest w stanie się ze sobą dogadać. A jak kiedyś zmienię MySQL na PostgreSQL to też nie będę musiał zmieniać wszystkiego, a tylko część webową - bo tylko ona dotyka MySQL.
Hmm. Ciekawe rozwiazanie pod warunkiem iz projekt jest bardzo maly i ogranicza sie do przesylania danych w max kilku MB. W moim przypadku moj projekt w pewnym momencie moze siegnac przesylu danych rzedu kilku GB w miesiacu. Ja satwiam na na uzywane stare telefony bo sa tansze od Raspbery Pi i maja czasem lepsze parametry. Jeszcze gdyby tylko dalo sie w latwy sposob czyscic telefony z bezuytecznych aplikacji
0
Chcesz iść w prawie martwe technologie. Nie ma to sensu.
Kilka GB to żadna wielkość.
Napisz to co chcesz w .NET Core i będziesz miał na Windows i linuxy w tym Raspberry. Jak chcesz tanio to jakieś poleasingowe PC za 150 PLN z linuxem.
0
Gdzies czytalem iz rynek mobilny staje sie numer 1 obecnie i ze nawet producenci procesorow przestawili sie na technologie mobilne i ze juz produkuja laptopy z proxesorami ARM nowej technologii. Zapewne chodzi im o energooszczednosc. Ja tez wybralem stare telefony ze wzgledu na energooszczednosi i wbudowany LCD. Jesli chcesz przeniesc siedzibe to pakujesz telefony w kieszen i marsz a z PC juz masz klopot - do tego awaryjnosc podzespolow. Widzialem nieraz na filmikach YT ze hindusi robia juz farmy mobilne gdzie telefony dzialaja jako servery. Czy kod napisany w .NET Core bede musial emulowac na linuxie?
0
Czy kod napisany w .NET Core bede musial emulowac na linuxie?
.NET Core natywnie działa na Linuksie (także Raspberry Pi, ale nie 1 i 0).
i ze juz produkuja laptopy z proxesorami ARM nowej technologii
I to nie od dziś, takie laptopy (i tablety!) są dostępne od pewnego czasu, ale bardzo mało popularne. Między innymi z uwagi na brak oprogramowania. Trochę być może się zmieni, bo możemy teraz emulować x86 na ARM, podobno "bez większych kosztów wydajności".
Kilka gigabajtów danych czy kilka megabajtów nie zmienia zasady - telefon nie wysyła danych bezpośrednio do bazy danych. Zrób warstwę pośrednią.
BTW, mam też projekt, gdzie to telefony (z Windows Phone 8 i Windows 10) wysyłają dane do systemu ;)