novembre 2004 - Posts
Se qualche partecipante alla Macromedia Conference tenuta oggi a Milano e Giovedì scorso a Roma vuole le slide/demo della mia sessione mi faccia un fischio in posta elettronica.
9090 http://www.windowsmobile.it/prodotti/qtek9090/index.asp
Evoluzione del 2020. Ha tutto: GSM, GPRS, Second Edition, Bluetooth e Wi-Fi 802.11b con ben 128 Mb RAM. Quadriband. Software incluso per gestione Fax.
8010 http://www.windowsmobile.it/prodotti/qtek8010/index.asp
E' uno SmartPhone Second Edition.
S100 http://www.windowsmobile.it/prodotti/qteks100/index.asp
Pocket PC Phone Edition 2003 SE. Dimensioni compatte e meno caratteristiche rispetto al 2020 e al 9090.
Ero fuori per lavoro e mi serviva il GPS...quindi ho aspettato qualche giorno per installare la versione 3.07 di Tom Tom Navigator...mi sembra un attimo più veloce e soprattutto non fa casino quando si telefona con la Phone Edition.
Ha il pieno supporto anche per la Second Edition di Windows Mobile 2003.
Ecco il link per il download http://www.tomtom.com/support/rightnow.php?Page=http%3A//support-it.tomtom.com/cgibin/it.cfg/php.exe/enduser/std_alp.php%3Fp_lva%3D%26p_li%3D%26p_page%3D1%26p_prod_lvl1%3D30%26p_prod_lvl2%3D%257Eany%257E%26p_cat_lvl1%3D7%26p_search_text%3D%26p_new_search%3D1%26p_search_type%3D3
Il giorno 18 novembre a Roma e in replica il 25 a Milano, DevLeap sarà presente con una sessione sponsorizzata da Microsoft su ASP.NET alla Macromedia Conference From A to Web.
La sessione riguarda la programmazione OO in ASP.NET, l'architettura delle richieste, l'object context, la pipeline di esecuzione, la scrittura di classi base custom, http handler e http module custom, l'accesso ai dati ottimizzato e una veloce panoramica dei mobile controls.
Questa l'agenda dell'intera manifestazione http://www.macromedia.com/it/events/fatw_04/agenda.html.
Ci vediamo in loco se ci sarete.
Tale metodo nel .NET Framework viene usato spesso per fornire a componenti o servizi (fra cui i Web Service) un DataSet contenente solo le modifiche effettuate al "vero" DataSet cu cui sta lavorando il client. E' buona norma infatti, dopo aver ottenuto i dati e averci fatto delle modifiche offline, "rimandare sul cavo solo e esclusivamente le cose che servono" evitando di ripassare l'intero DataSet contentente anche le righe non modificate.
Purtroppo nel .NET Compact Framework non esiste il metodo GetChanges del DataSet, quindi siamo costretti a ripassare l'intero DataSet sul cavo affinche il componente utilizzi il DataAdapter per salvare le modifiche sul database. Prima però di percorrere questa strada potrebbe essere conveniente scriversi 10 righe di codice che eseguono esattamente le operazioni esposte dal metodo GetChanges presente nella versione Desktop.
Si può partire da Anakrino o Reflector per vedere cosa fa il metodo GetChanges: tale metodo in realtà richiama l'altro overload (richiamabile ovviamente anche in modo diretto).
Ecco l'estratto
public DataSet GetChanges()
{
return this.GetChanges(DataRowState.Modified | (DataRowState.Deleted | DataRowState.Added));
} |
Il metodo con overload è fatto così:
public DataSet GetChanges(DataRowState rowStates)
{
DataSet set1 = null;
if (!this.HasChanges(rowStates))
{
return null;
}
set1 = this.Clone();
bool flag1 = set1.EnforceConstraints;
set1.EnforceConstraints = false;
foreach (DataTable table1 in this.Tables)
{
DataTable table2 = set1.Tables[table1.TableName];
foreach (DataRow row1 in table1.Rows)
{
if (this.ShouldWriteRowAsUpdate(row1, rowStates))
{
table1.CopyRow(table2, row1);
}
}
}
set1.EnforceConstraints = flag1;
return set1;
} |
Dopo un test sulla presenza di modifiche nel DataSet viene clonato (.Clone copia lo schema, le relazioni e i constraint, non i dati) sull'oggetto set1. Viene poi effettuato un ciclo su tutte le tabelle e all'interno un secondo ciclo su tutte le righe. Il metodo ShouldWriteRowAsUpdate è dichiarato internal e restituisce true se la riga in questione ha subito una modifica (specifica nel caso in cui si sia richiamato direttamente GetChanges con un particolare RowState). Se la risposta è true viene richiamato CopyRow, altro metodo internal della classe DataTable che non fa altro che copiare i dati di row1 in una nuova riga della table2.
Volendo ricostruire questo metodo per il .NET Compact Framework siamo costretti a ridefinire anche i metodi ShouldWriteRowsAsUpdate e CopyRow (tra l'altro CopyRow chiama altri metodi e campi internal fra cui il Record Manager e quindi diventa problematico ricostruirlo per intero).
Vi propongo una soluzione che può essere ampliata/modificata in base alle effettive esigenze.
Si parte dal presupposto di avere un oggetto DataSet denominato ds.
if(ds.HasChanges())
{
// Ovviamente meglio farsi un assembly esterno per questi
DataSet set1 = null;
set1 = ds.Clone();
bool flag1 = set1.EnforceConstraints;
set1.EnforceConstraints = false;
foreach (DataTable table1 in ds.Tables)
{
DataTable table2 = set1.Tables[table1.TableName];
foreach (DataRow row1 in table1.Rows)
{
// Anche questo metodo è copiato nel form....Meglio un assembly esterno
if (ShouldWriteRowAsUpdate(row1, DataRowState.Modified | (DataRowState.Deleted | DataRowState.Added)))
{
// Non si può fare Add altrimento il RowState sarebbe sempre Added
table2.ImportRow(row1);
}
}
}
set1.EnforceConstraints = flag1;
Dopo aver salvato EnforceConstaints (per ripristarlo in fondo al ciclo) ripercorriamo i passi del metodo classico. Doppio ciclo, chiama al metodo ShouldWrite....che ci dirà se la riga ha subito modifiche, e se la risposta è true, ci portiamo la riga nella tabella corrispondente del nuovo DataSet. Si usa ImportRow e non AddRow perchè è necessario mantenere lo stato delle proprietà: con Add la riga verrebbe aggiunta e quindi avrebbe un RowState = DataRowState.Added...quindi verrebbe trattata come riga aggiunta quando invece potrebbe essere tranquillamente Deleted o Updated nel DataSet in questione.
Tra l'altro il metodo ImportRow è identico nel funzionamento al metodo CopyRow, ma come abbiamo già detto è pubblico, quindi richiamabile nel nostro esempio, mentro CopyRow è internal.
Il metodo ShouldXXX è identico a quello presente nel FW desktop (va ricostruito comunque in quanto internal):
private bool ShouldWriteRowAsUpdate(DataRow row, DataRowState _rowStates)
{
DataRowState state1 = row.RowState;
if (((int) (state1 & _rowStates)) != 0)
{
return true;
}
for (int num1 = 0; num1 < row.Table.ChildRelations.Count; num1++)
{
DataRowVersion version1 = (state1 == DataRowState.Deleted) ? DataRowVersion.Original : DataRowVersion.Current;
DataRow[] rowArray1 = row.GetChildRows(row.Table.ChildRelations[num1], version1);
for (int num2 = 0; num2 < rowArray1.Length; num2++)
{
if (this.ShouldWriteRowAsUpdate(rowArray1[num2], _rowStates))
{
return true;
}
}
}
return false;
}
Come si nota questo metodo controlle eventuali modifiche alla riga (in base a quanto abbiamo espresso nel primo frammento di codice: Added, Modified,Deleted o una combinazioni di essi), eseguendo tale controllo anche sulle righe Child ed in caso affermativo invocando rivorsivamente lo stesso metodo.
Buon lavoro.
Airscanner è stato il primo team a rilasciare un antivirus per CE.Dust, il primo virus per Windows CE.
Oggi rilascia la prima beta stabile della versione per SmartPhone.
Link alla notizia http://bink.nu/?ArticleID=2833
Link al prodotto http://airscanner.com/
WSE (Web Service Enhancements) rappresenta il modo con cui Microsoft propone aggiornamenti alle funzionalità relative ai Web Service native nel Framework .NET. Visto che la tecnologia e gli standard relativi a SOAP stanno progredendo ad un ritmo elevato, piuttosto che aggiungere funzionalità direttamente in .NET, Microsoft ha preferito aggiungere un “prodotto esterno” che si aggiorni ogni qualvolta vengano proposte specifiche WS. Il prodotto è attualmente alla versione 2.0 SP1. Dalla versione 1 alla Technical Preview della 2.0 sono cambiate molte cose e anche dalla Technical Preview alla versione finale, molte classi, interfacce e metodi sono stati stravolti. Questi aggiornamenti radicali non sarebbero applicabili al Framework .NET dove invece la compatibilità è uno dei cardini del prodotto.
Una delle funzionalità più importanti è sicuramente la possibilità di gestire Services (notare che non ho scritto Web Services) che lavorano in modo totalmente indipendente dal protocollo di trasporto. In .NET i Web Service sono confinati all’utilizzo via Http. In effetti, fin dal lontano 1998, parlando di SOAP, occorreva segnalare che il Simple Object Access Protocol è il protocollo per costuire messaggi che possono viaggiare su qualunque protocollo di trasporto. I protocolli nativamente supportati sono InProcess, TCP/IP e Http (in WSE si parla di Channel per far riferimento al canale di comunicazione). E’ ovviamente possibile implementare altri protocolli di comunicazione fra mittente e destinatario: in WSE troviamo due classi (SoapSender e SoapReceiver)
Continua su week.it http://www.weekit.it/weekit/unico/art006004039926.jsp
Windows Mobile 2003 Second Edition si differenzia dalla versione classica per le caratteristiche grafiche. Per prima cosa sono aumentati i pixel sullo schermo: sul Pocket PC si passa da una risoluzione QVGA da 240x320 a 96 dpi a una VGA da 480x640 a 192 dpi. Per lo SmartPhone si passa da una risoluzione di 176x220 a 96 dpi a una risoluzione QVGA da 240x320 a 131 dpi. La versione Pocket PC supporta anche una risoluzione Square da 240x240 (96 dpi) oppure 480x480 (192 dpi). L’acronimo QVGA significa Quarter VGA.
La seconda novità riguarda solo la versione Pocket PC e consente nativamente di orientare lo schermo in modalità Portrait (come in precedenza), oppure Landscape. Non tutti i device consentiranno lo switch fra le varie modalità: in altre parole non è richiesto ai produttori di device di implementare la possibilità per l’utente di modificare le impostazioni dello schermo: troveremo quindi device con risoluzione Square 480x480, device con orientamento Landscape 480x640 e device con la possibilità di impostare le caratteristiche dello schermo.
Se uno dei punti saldi dello sviluppo per Pocket PC e SmartPhone era proprio la dimensione dello schermo e i dpi, dalla Second Edition le cose si complicano anche sul fronte interfaccia utente. Un’applicazione per il mondo mobile lavora su processori diversi (sono oltre 15 i processori più comuni per i device basati su Windows CE), su caratteristiche hardware, come ad esempio la dimensione della RAM, e di conseguenza lo sviluppatore deve adattare (con EVC++ 4.x anche ricompilare) i propri eseguibili, dll, setup alle varie piattaforme. L’unica certezza era appunto la dimensione dello schermo di una categoria di device.
Ci sono diverse tecniche per adattare l’interfaccia utente a queste nuove caratteristiche: la prima consiste nel definire tanti oggetti Windows Form dal designer di Visual Studio ottimizzate per le varie risoluzioni e un form principale, assolutamente vuoto che legge la configurazione dello schermo e visualizza il form corretto. La seconda è disegnare il form con la prima tipologia di risoluzione, entrare nella sezione “Windows Form Generated Code”, e copiare il codice prodotto un una funzione esterna. Si adatta poi il form alla seconda risoluzione da supportare ripetendo l’operazione di copia in una seconda funzione.
Continua su week.it http://www.weekit.it/weekit/unico/art006004040151.jsp
Nell''articolo Week.it di Marco Gatti, si trovano una serie di riflessioni (scritte e non) sul mondo dell IT. Come sempre Marco centra l'obiettivo.
http://www.weekit.it/weekit/unico/art006004040132.jsp
il vostro capo vi chiama anche la domenica ? l'amante vi rompe le scatole quando non dovrebbe ? oppure la moglie rompe le scatole quando siete con l'amante ?
Nessun problema: e' uscito il nuovo filtro "antispam"...si fa per dire...per SmartPhone e Pocket PC Phone Edition.
Blocca le chiamate che non vogliamo ricevere in base al chiamante, alle chiamate anonime etc etc e lascia passare le altre chiamate...finalmente possiamo smettere di mettere la vibrazione (sempre imbarazzante :-)) ai gruppi di chiamate...con l'interfaccia di SmartFilter di NovoSec è tutto rapido e semplicissimo.
Ecco il link al prodotto http://www.novomobile.com/smartfilter.php
More Posts
Next page »