Bejegyzés

Tömörített adatok átvitele C# és PHP között

/in /by

WebSyX beépülő modulunk megváltozott vagy teljes adathalmazokat tölt fel webáruházak felé. A feltöltött adatok jól tömöríthetőek, TCP szinten tömörítjük is őket, de ez néha nem elég.

Több ügyfelünk jelezte, hogy a webszerver nem tud 1-2MB-nál nagyobb POST adatokat fogadni. Ezen lehet állítani, de ha a szerver nem saját, akkor a szolgáltató általában elhárítja az ilyen kéréseket. A WebSyX már korábban is darabolt bizonyos adatokat. Azok az adatok, amelyek biztosan nagyok (termékképek, dokumentumok) már eddig is 10-es, 20-as csomagokban utaztak. Bizonyos esetekben azonban a termék készlet feltöltése is elérheti az 1-2MB-ot.

compression

Hogy az ügyfeleink (pontosabban az ő webesük) meg tudja oldani a szinkront, egy új beállítást vezettünk be. Az adatokat tömörítve is lehet küldeni. Ilyen esetben a megérkező adat egy csomagolt XML.

Feltöltés oldalon használt:
DeflateStream sw = new DeflateStream(ms, CompressionMode.Compress)

Webszerver oldalon használt:
$data = gzinflate(base64_decode($_POST[“xmldata”]));

A bejegyzés azért íródott, mert ismét belefutottunk az informatikai inkompatibilitásba. Még a Concorde Értékpapír Zrt-nél találkoztunk azzal, hogy a Corba (akkor még XML helyett ez volt) másképp kezeli a dátumokat Delphiből és Javaból. Itt is hasonló a helyzet. A sima GZipStream-mel előállított, tömörített adat csak nem akart kicsomagolódni gzdecode()-dal és gzuncompress()-szel, a gzinflate() lett a megoldás. Sőt az gzdecode() függvény az alap PHP-nak nem is része, míg a gzencode() igen. Ez is érdekes…

Ami hiányzik a .NET-ből

/in , /by

Mindig is irigykedtem, hogy sok fejlesztő publikál példa kódokat, amelyek másoknak is jók lehetnek. Most mi is összegyűjtöttünk egy párat, hátha…

 

Tömb összefűzés, rendezési opcióval

public static T[] Concatenate<T>(params T[][] arrays)
{
  return Concatenate<T>(null, arrays);
}
public static T[] Concatenate<T>(Comparison<T> comparison, params T[][] arrays)
{
  List<T> result = new List<T>();
  foreach (T[] array in arrays)
    result.AddRange(array);
  if (comparison != null)
    result.Sort(comparison);
  return result.ToArray();
}


Tömb "egyszeresítés"

public static T[] Distinct<T>(T[] array)
{
  return Distinct(array, null);
}
public static T[] Distinct<T>(T[] array, Comparison<T> comparison)
{
  List<T> result = new List<T>();
  foreach (T item in array)
    if (!result.Contains(item))
  result.Add(item);
  if (comparison != null)
    result.Sort(comparison);
  return result.ToArray();
}


Tömb összekavarás

public static T[] Shuffle<T>(T[] array)
 {
  Random rnd = new Random();
  int n = array.Length;
  while (n > 1)
  {
    int k = rnd.Next(n);
    n--;
    T temp = array[n];
    array[n] = array[k];
    array[k] = temp;
  }
  return array;
 }


Várakoztató kurzor kezelő

public class WaitCursor : IDisposable
{
  public WaitCursor()
  {
    ContextHandler.WaitCursorOn();
  }
  public void Dispose()
  {
    Dispose(true);
    GC.SuppressFinalize(this);
  }
  private bool disposed = false;
  protected virtual void Dispose(bool disposing)
  {
    if (!this.disposed)
    {
      if (disposing)
     {
     }
     ContextHandler.WaitCursorOff();
   }
   disposed = true;
 }
 ~WaitCursor()
 {
   Dispose(false);
 }
}


X64 kezelő

public static class X64Handler
{
  public static bool IsX64 { get { return IntPtr.Size == 8; } }
  public static string Display(bool suppress32) { return IsX64 ? "x64" : suppress32 ? null : "x86"; }
}
 

Még mindig nagyon gyenge a .NET Entity Framework 4.0 béta

/in , /by

Találós kérdéssel indítok. Tehát mire gondoltam?

Mindenki nagyon várja. Marketingre sokat költ a Microsoft. A fejlesztői portálok tele vannak vele, mert remek eszköz. Nem a megjelenítést szolgálja, azaz nem GUI. Mindenki használja. Mindenki meg van vele elégedve. Mindenki szidja. Mindenki mondja, hogy nem baj, a következő releaseben megoldják. Nagyon gyorsan, akár félévente jön ki belőle új release. Adatbázissal kapcsolatos. Adatbázist érünk el vele.

 

Igen, kitalálhattátok, hogy EntityFramework. Témánál vagyunk.

Megjelent a 4.0 béta és az alábbi bejegyzést döbbenten olvastam. Itt kell tartani egy termék 4.0-s verziójával? Ezek a nagy előrelépések a 3.0-hoz képest? A cikk itt olvasható.

Nézzük megy egy kicsit jobban, mire is gondoltam, amikor a döbbenet szót használtam. Kollégáim már tudják mire gondolok, de tudja meg más is!

  • Egy ilyen készültségi szinten lévő projektben kell olyan optimalizációs lépéseket megtenni, minthogy nem hoz le minden oszlopot egy subselect, csak ami kell nekünk?
  • COUNT(1) nyelvi elem direkt használata, amikor az a célszerű.
  • A legnagyobb, az IN SELECT. Komolyan gondolja valaki, hogy a 4.0-ig kell várni egy kliens oldalon is jelenlévő adatstruktúra (tömb) és SQL oldalon is elérhető nyelvi konstrukció (WHERE xx IN (x,y,z…)) összekapcsolására?

Igen, emiatt van tele minden fejlesztői portál olyan jellegű kérdésekkel, hogy “Hogy tudok két táblát összekapcsolni LINQ-ban, EntityFramework-kel?” Ezek szerint nem segítség, hanem csak egy hozzászoktató eszköz, ami függőséget okoz és ha függő lettél, akkor minden fejlesztéshez a megrendelővel vetetni fogsz MsSQL Server 2010-et, supporttal, majd kell még 5 profi kolléga, aki natív SQL-hez nem ért, de kiválóan függő EntityFramework-kel.

A saját, fentihez hasonlító dolgokat megvalósító keretrendszserünk első bétája ennél sokkal több dolgot valósított meg. Mert a való életre próbáltuk alkalmazni és a tervezéskor használt use-case-ek a tapasztalatból táplálkoztak.

Ha várni kell a Windowsban – A jó öreg homokóra

/2 hozzászólás/in /by

Gyakran fordul elő, hogy homokórát kell megjelenítenünk, mert valamilyen művelet hosszabb időt vehet igénybe. A felhasználó pedig várakozzon, ahelyett, hogy a beviteli mezőket próbálja szerkeszteni vagy a gombokat működésre bírni.

Régebbi programozási nyelvekben (Delphi, FoxPro) a hosszú műveletek automatikusan beállították a homokóra üzemmódot. Viszont nem kezelték jól a beágyazott műveleteket, azaz 10 darab SELECT végrehajtása egymás után 10 homokórás villogást eredményezett. Ez a mai világban inkább szégyenletes, mint felhasználóbarát.

 

Ezt a problémát oldottuk meg az alábbi kódrészlettel:

using System;
using System.Windows.Forms;
namespace SymbolTech.Common
{
    public class WaitCursor : IDisposable
    {
        private static int waitcursorlevel = 0;

        public WaitCursor()
        {
            waitcursorlevel++;
            if (waitcursorlevel > 0)
                Cursor.Current = Cursors.WaitCursor;
        }

        public void Dispose()
        {
            waitcursorlevel--;
            if (waitcursorlevel == 0)
                Cursor.Current = Cursors.Default;
        }
    }
}

Minden (hosszabb) műveletet beágyazunk egy using(new WaitCursor()) blokkba. Ezzel a következő előnyöket érjük el:

  1. A műveletek minden esetben “homokórázni” fognak.
  2. A beágyazott műveletek (külső blokk már homokórában dolgozik, a belső, mondjuk 100 iteráció is bekapcsolja a homkórát) nem fogják villogtatni a kurzort.
  3. Véletlenül sem felejtjük el visszakapcsolni az alapértelmezett kurzort, amennyiben a műveletek végrehajtásra kerültek.

 

Lássunk egy példát, a használatára:

        private void DummyMethod()
        {
            using (new WaitCursor())
            {
                Thread.Sleep(100);
            }
        }
        private void button1_Click(object sender, EventArgs e)
        {
            using (new WaitCursor())
            {
                Thread.Sleep(500);
                for (int i = 0; i < 10; i++)
                    DummyMethod();
            }
        }

A példában egy beágyazott, többször (10x) végrehajtott műveletet látunk, amelyek összességében 1.5mp-re átkapcsolnak homokórára, de közben nem villog a kurzor.

TabCsapda – hol a kurzor?

/in /by

Tesztelő csapatunk fura hibával állt elő, nemsokára megjelenő program release-ünk áttekintésekor. A TAB-bal való navigáció – amely a Win95 környékén jelenhetett meg és minden felhasználó hozzászokott az elmúlt 15 évben – valahol elveszti működését és megáll.

A GridControl volt a hibás, ugyanis furcsa működéséből adódóan egy táblázatban is lehet tabbal lépkedni, vagy a sorok vagy a cellák között és amikor a végére érünk, nem tudunk merre menni. Nem is tudom, hogy miért ez az alapértelmezett működés, de kikapcsoltuk. Sok dolgunk nem volt, 2 (!!!) sort kellett a megfelelő helyen adaptálni és az összes termékünk következő kiadásában megjelenik a TabCsapda elleni megoldás.

Kivételek típusai – melyiket dobjam?

/1 Hozzászólás/in /by

A kivételkezelés alatt sok fejlesztő a catch ág megvalósítását gondolja, de ugyanolyan fontos a kivételek eldobása is. Nem szabad azzal megelégedni, hogy dobunk egy ApplicationException-t, sokkal precízebb, ha a típusos esetekben (rossz paraméter, nem jó képformátum) a beépített kivételosztályokat használjuk.

Lássuk, mik ezek:

Kivétel osztály Kiváltás oka
SystemException Futásidejű hiba, a kivételes ősosztálya
AccessException Egy típus elemeléréseinek hibája (metódus, mező, property)
ArgumentException Metódushívás esetén hibás paraméter
ArgumentNullException Metódushívás esetén null paraméter, ha azt a metódus nem tudja kezelni
ArgumentOutOfRangeException Paraméter értéke adott határokon kívül esik
ArithmeticException “Matematikai” hiba
ArrayTypeMismatchException Típusos tömbön végzett művelet egy idegen típussal
BadImageFormatException Rossz képformátum
CoreException Futásidejű kivételes ősosztálya
DivideByZeroException Nullával való osztás
FormatException Argumentum formátuma nem helyes (pl: String.Format)
IndexOutOfRangeException Tömb indexelése túlmutat a határokon
InvalidCastExpression Futásidejű Cast művelet nem hajtható végre
InvalidOperationException Nem megfelelő (idejű?) művelet hívása
MissingMemberException DLL verziószám ütközés, eltérés metódushívás közben
NotFiniteNumberException Nem valós szám (decimal, float; NaN, Infinity)
NotSupportedException Nem létező metódus hívása (reflection?)
NullReferenceException NULL értékű változó által hivatkozott objektum elérése
OutOfMemoryException Memória elfogyás
StackOverflowException Verem műveletek memória elfogyása (rekurízió)

A fenti lista számos lehetőséget kínál a fejlesztőknek a megfelelő kivétel eldobásában. Ezek használata nagyban megkönnyíti a hibakezelést és hibakeresést, a metódus írója pedig publikálhatja, hogy mit várt és mit kapott.

Egyedi sorosítás – IXMLSerializable megvalósítás

/in /by

C#, remek nyelv. Szinte mindent lehet sorosítani, XML-be menteni. Nem is kell kézzel ezeket megírni, összerakni. De egy pár dolog kimaradt. Talán oka is van, hogy miért, de ez nem lényeg. A lényeg, hogy meg lehet valósítani.

A generic List<>-et lehet sorosítani, de előtte kell egy plusz származtatási szinten készíteni. Dictionary<T,U>-t nem lehet. De van megoldás. Csináljunk egy sorosítható Dictionary-t.

    [XmlRoot("Dictionary")]
    public class SerializableDictionary<TKey, TValue> : IXmlSerializable
    {
        public XmlSchema GetSchema()
        {
            return null;
        }
        public void ReadXml(XmlReader reader)
        {
            XmlSerializer keySerializer = new XmlSerializer(typeof(TKey));
            XmlSerializer valueSerializer = new XmlSerializer(typeof(TValue));
            bool wasEmpty = reader.IsEmptyElement;
            reader.Read();
            if (wasEmpty)
                return;
            while (reader.NodeType != XmlNodeType.EndElement)
                try
                {
                    reader.ReadStartElement("Item");
                    reader.ReadStartElement("Key");
                    TKey key = (TKey)keySerializer.Deserialize(reader);
                    reader.ReadEndElement();
                    reader.ReadStartElement("Value");
                    TValue value = (TValue)valueSerializer.Deserialize(reader);
                    reader.ReadEndElement();
                    reader.ReadEndElement();
                    reader.MoveToContent();
                    this.Add(key, value);
                }
                catch { }
            reader.ReadEndElement();
        }
        public void WriteXml(XmlWriter writer)
        {
            XmlSerializer keySerializer = new XmlSerializer(typeof(TKey));
            XmlSerializer valueSerializer = new XmlSerializer(typeof(TValue));
            foreach (TKey key in this.Keys)
            {
                writer.WriteStartElement("Item");
                writer.WriteStartElement("Key");
                keySerializer.Serialize(writer, key);
                writer.WriteEndElement();
                writer.WriteStartElement("Value");
                TValue value = this[key];
                valueSerializer.Serialize(writer, value);
                writer.WriteEndElement();
                writer.WriteEndElement();
            }
        }
    }

Ahogy látható, csak a saját szintünket kell megvalósítani, a TKey és TValue elemek sorosításával már a saját osztályuk foglalkozik. Extrém eset ha a TValue is egy sorosítható Dictionary (valós példát nem tudunk jelenleg mondani), ilyenkor ennek az objektumnak a sorosításakor szintén a fenti algoritmus fog lefutni.

Diagram engine – miért C#

/1 Hozzászólás/in , /by

Ügyviteli rendszereknél ritka, hogy diagramot jelenítünk meg valamit, hiszen minden adat táblákban van, azok megjelenítéséhez pedig ideális valamiféle grid. Néha szoktak beépített grafikon segítségével felhasználókat elképráztatni, de az egyedi rajzolásos digram nem mindennapos.

Az üzletkötőink, ügyviteli szakembereink sem értették, hogy mit akarunk ezzel, miért nem jó szerintünk a sima kis lista. Csak a végén értették meg, hogy mit is akartunk.

Ezt:

voucherdiagram

Hogyan is jött létre ez a – joggal innovációnak nevezhető – modul, amely minden ügyviteli termékünkben megjelenik és sok pozitív felhasználói visszajelzést indukált? A bizonylatok és egyéb adatelemek közti reláció, adatkapcsolat adott, erre épül maga az alkalmazás. No de ezt hogy jelenítsük meg egy gráfban, hogy  felhasználó is kedvet kapjon és használja?

Csapatunk 3 napon keresztül tervezett, brainstormingolt. Számos ötlet jelent meg a fejekben és a nagy prezentációs falon, ezen ötletek kb. 50% bele is került a megvalósult rendszerbe. Az elvárások tisztázása után kezdődött a fejlesztés. Programnyelv C#, ennek GDI és GDI+ lehetőségei kiváló kiaknázásra való területet jelentettek számunkra.

Lépések:

  • Építsünk egy saját controlt.
  • Bármilyen megjelenni kívánó objektum feleljen megy egy IDiagramDrawItem interfésznek, amely egy metódust definiál void Draw() és információt szolgáltat arról, hogy melyik rétegben jelenik meg a kirajzolandó adatelem int ZOrder { get; }.
  • Rajzolás megvalósítása
    • override Paint()
    • void ClearAndDrawBackground()
    • void SortByZOrder()
    • foreach(... item.Draw()...)

Már a tervezési fázisban is láthatóvá vált, hogy lesznek optimalizálási kérdések, problémák, amelyek a témakör izgalmasabb részét jelentik.

Repository, hogy ne szaggasson a kép. Egyedileg rajzoló eljárások rákfenéje a sok GDI objektum, amely memóriában és időben is költséges. A memóriabeli költségeket, mivel IDisposasble, meg lehet oldani, de sokáig tart minden OnPaintben Font-os, Pen-t és Brush-t létrehozni. Erre született megoldásként, hogy a diagram ezeket publikálja, tárolja, elérhetővé teszi eg példányban, egy alkalommal való létrehozással a rajzolni képes objektumok felé. Performancia mérést végeztünk, egy átlagos diagram 740 alkalommal tud kirajzolódni egy másodperc alatt. Nem rossz, megfelel.

GraphicsPath, hogy lekerekített sarkú legyen a doboz. A C# GDI+ lehetőséget kínál arra, hogy vonalak és görbék segítségével egy “utat” hozzunk létre, amely felhasználható rajzolásra és kitöltésre egyaránt. Megvalósítottuk. Mivel ez is költséges, minden objektum a mérete alapján (amely nem állítható megjelenítés közben) első felhasználáskor (late-init) létrehozza a GraphicsPath objektumot.

LinearGradientBrush, hogy átmenetes legyen a dobozok háttere. A legnagyobb kihívás a színátmenetes doboz volt, amely egy pontoktól függő GradientBrush lett. Ennek szintén elég egy példányban léteznie, de a doboz pozíciójának függvényében kell felparaméterezni. A (rendszer által) mozgatható dobozok pedig ezen tulajdonságukat gyakran változtatják, de erre is született megoldás: late-init és re-init-by-move.

És ekkor még nem ért véget a gondolkodás, a dobozok esztétikus elhelyezésének algoritmusa felér egy komolyabb diplomamunka témakörével, erről egy következő cikkben.

Windows 7 tálca újdonságai – fejlesztői szemmel

/1 Hozzászólás/in , /by

Napvilágot látott (le is tölthető, meg is vásárolható lassan) a Microsoft új operációs rendszere, amely felhasználói szemmel újdonság, fejlesztői szemmel kihívás.

Az alábbi linken pár információval szolgálnak arról, mik is ezek az újítások. Én csak a tálca újdonságait emelném ki. Ezidáig a felhasználót a jobb alsó sarokban lévő úgynevezett értesítési területen lehetett informáli dolgokról. Milyen folyamatok futnak, mennyi ideig tart még a DVD megírása, a fájl letöltése.

Ezt most egy kicsit megbolondították és elérhetővé tették folyamatjelzők és ikonok megjelenítését a tálcán, ahol eddig a program főablakának címe szerepelt és jobb esetben az alkalmazás ikonja (számos fejlesztő felejt el ikont adni). A lehetőségek között szerepel:

  • Véges folyamatjelző
  • Végtelen folyamatjelző (nem kiszámítható befejezési idővel)
  • Hibajelző (piros)

taskbarwithprogressandoverlays

És ehhez elég lesz a .Net framework 4.0?

Elég, sőt 3.5-tel is működni fog, le kell hozzá tölteni a WindowsApiCodecPack-et (4MB, súgóval együtt 19MB), amely forrásfájlokat szolgáltat számunkra, hogy a Windows7 fenti szolgáltatásait elérjük. DirectX is kell hozzá a leírás szerint, de ez valószinüleg akkor szükséges, ha a CodecPack DirectX-es szolgáltatásait is szeretnénk használni.

Lehetőségünk lesz elérni a ITaskBarList3 interfész SetOverlayIcon, SetProgressState és SetProgressValue metódusait, amivel lehetőségünk van a felhasználóinkat informálni egy hosszabb programfolyamat állapotáról.

Referenciaként a Core és Shell szerelvényeket kell a projekthez hozzáadni, ezen névterekben pedig megtalálhatóak a szükséges osztályok:

  • Microsoft.WindowsAPICodePack.Shell.Taskbar
  • Microsoft.WindowsAPICodePack.Shell.Taskbar.ProgressBar
  • Microsoft.WindowsAPICodePack.Shell.Taskbar.OverlayIcon

Ezen kívül a ProgressBarExt és OverlayIconExt osztályok segítségével a Windows XP óta, a sok ablak megjelenítésekor összecsoportosuló programablakok mindegyike külön folyamatjelzővel látható el.

Tesztelés folyamatban…