ڈی سیریلیائزیشن: یہ کیا ہے، ڈیٹا کی بحالی کا عمل

ڈی سیریلیائزیشن کیا ہے؟

ڈی سیریلیائزیشن بائٹ اسٹریم یا ساختی متن کو پروگرامنگ لینگویج آبجیکٹ میں تبدیل کرنے کا عمل ہے۔ موبائل ڈویلپمنٹ میں، یہ عمل ہر بار ہوتا ہے جب ایپلیکیشن سرور سے جواب وصول کرتی ہے: ایک JSON سٹرنگ User، Order یا Product کلاس کے انسٹینس میں بدل جاتی ہے۔ صارف کو ڈیٹا دکھانے والی اسکرینوں کا استحکام براہ راست ڈی سیریلیائزیشن کی درستگی پر منحصر ہے۔

سیریلیائزیشن سے فرق

سیریلیائزیشن اور ڈی سیریلیائزیشن باہمی معکوس عمل ہیں، عملی طور پر شاذ و نادر ہی متوازن ہوتے ہیں۔ سیریلیائزیشن سرور کو بھیجنے کے لیے آبجیکٹ کو سٹرنگ میں تبدیل کرتی ہے، جبکہ ڈی سیریلیائزیشن موصولہ سٹرنگ سے آبجیکٹ کو بحال کرتی ہے۔ سرور ایک ایسا فیلڈ بھیج سکتا ہے جو کلائنٹ ماڈل میں موجود نہیں ہے، مختلف تاریخ کا فارمیٹ استعمال کر سکتا ہے، یا نمبر کے بجائے null واپس کر سکتا ہے۔ Square Engineering (2025) کے مطابق، فارمیٹ کی غیر ہم آہنگی Android ایپلیکیشنز میں 23% نیٹ ورک پرت کی غلطیوں کا سبب بنتی ہے۔ خطرے کو کم کرنے کے لیے، OpenAPI کے ذریعے اسکیما ورژننگ اور سخت معاہدہ تصریح استعمال کی جاتی ہے۔

ڈی سیریلیائزیشن کے لیے ڈیٹا فارمیٹس

JSON انسانی پڑھنے کی اہلیت اور بلٹ ان سپورٹ کی وجہ سے موبائل APIs کے لیے سب سے مقبول فارمیٹ ہے۔ Google کا Protobuf زیادہ بوجھ والے سسٹمز میں استعمال ہوتا ہے — یہ JSON سے 3-6 گنا زیادہ کمپیکٹ ہے اور تیزی سے پارس ہوتا ہے، لیکن .proto فائلوں سے کوڈ جنریشن کی ضرورت ہے اور ٹولز کے بغیر پڑھنے کے قابل نہیں ہے۔ XML جدید موبائل ایپلیکیشنز میں کم عام ہے، تاہم یہ انٹرپرائز سسٹمز کی SOAP سروسز اور Android کنفیگریشن فائلوں میں استعمال ہوتا ہے۔ MessagePack ایک بائنری فارمیٹ ہے جو ساخت میں JSON سے ملتا جلتا ہے لیکن زیادہ کمپیکٹ ہے، ریئل ٹائم سسٹمز میں مقبول ہے۔

ڈی سیریلیائزیشن کیسے کام کرتی ہے

ڈی سیریلیائزیشن کا عمل تین مراحل سے گزرتا ہے۔ پہلے، ٹوکنائزیشن خام متن کو ٹوکنز میں تقسیم کرتی ہے: کلیدیں، سٹرنگیں، نمبر اور حد بندیاں۔ پھر نحوی تجزیہ ساخت کی درستگی چیک کرتا ہے — کیا بریکٹ بند ہیں، کیا اقتباس کی قسم درست ہے، کیا فارمیٹ RFC 8259 کے مطابق ہے۔ آخری مرحلہ ایپلیکیشن کے آبجیکٹ ماڈل پر میپنگ ہے، جہاں ہر JSON کلید کو نام رکھنے کی حکمت عملی کو مدنظر رکھتے ہوئے ایک کلاس پراپرٹی تفویض کی جاتی ہے۔

Reflection بمقابلہ Code generation

موبائل ڈویلپمنٹ میں میپنگ کے دو طریقے سامنے آئے ہیں۔ Reflection (Gson، JSONSerialization) Java Reflection API یا Objective-C رن ٹائم کے ذریعے رن ٹائم پر کلاس کی ساخت کا تجزیہ کرتا ہے — یہ لچکدار ہے اور اضافی کنفیگریشن کی ضرورت نہیں ہے، لیکن سست ہے اور زیادہ میموری استعمال کرتا ہے۔ Code generation (Moshi codegen، kotlinx.serialization، Codable) کمپائل ٹائم پر کوڈ تیار کرتا ہے: تیز، ٹائپ محفوظ اور reflection کے ذریعے اندرونی ساخت کو ظاہر نہیں کرتا۔ JetBrains اور Square پروڈکشن بلڈز کے لیے کوڈ جنریشن کی تجویز کرتے ہیں — Google بینچ مارکس میں کارکردگی میں 2-4 گنا اضافہ ہوتا ہے۔

struct User: Codable {
    let id: Int
    let name: String
    let email: String
    let createdAt: Date
}

let json = """
{
    "id": 42,
    "name": "Alice",
    "email": "alice@example.com",
    "created_at": "2026-06-01T12:00:00Z"
}
"""
let decoder = JSONDecoder()
decoder.keyDecodingStrategy = .convertFromSnakeCase
let user = try decoder.decode(User.self, from: data)

Swift میں JSON کو User ماڈل میں ڈی سیریلیائز کرنے کی مثال۔ convertFromSnakeCase حکمت عملی خود بخود snake_case API کلیدوں کو camelCase ماڈل پراپرٹیز میں تبدیل کرتی ہے — iOS پروجیکٹس میں ایک معیاری عمل۔ data پیرامیٹر URLSession کے ذریعے موصولہ سرور جواب کے خام بائٹس ہیں۔ try کے ذریعے ایرر ہینڈلنگ ایپلیکیشن کو کریش کیے بغیر ناقص JSON کو پکڑنے کی اجازت دیتا ہے۔

ڈی کوڈنگ حکمت عملیوں کا کردار

JSONDecoder چار کلیدی حکمت عملیوں کو سپورٹ کرتا ہے: useDefaultKeys (عین مطابق)، convertFromSnakeCase (snake_case → camelCase)، custom (closure) اور convertFromKebabCase (kebab-case → camelCase)۔ تاریخوں کے لیے، .iso8601، .secondsSince1970، .millisecondsSince1970 اور کسٹم dateFormatter دستیاب ہیں۔ صحیح حکمت عملی کا انتخاب مضبوط ڈی سیریلیائزیشن کی طرف پہلا قدم ہے، جو زیادہ تر فارمیٹ کی عدم مطابقت کی غلطیوں کو روکتا ہے۔

iOS پر ڈی سیریلیائزیشن

JSONDecoder iOS SDK میں ڈی سیریلیائزیشن کا معیاری طریقہ کار ہے، جو Codable پروٹوکول کے ساتھ کام کرتا ہے۔ JSONDecoder خود بخود JSON کو struct یا class انسٹینس میں پارس کرتا ہے، نیسٹڈ آبجیکٹس، اریز اور پریمیٹیو کو سپورٹ کرتا ہے۔ کسٹم لاجک کے لیے init(from: Decoder) طریقہ استعمال کیا جاتا ہے — یہ غیر معیاری فارمیٹس کو ہینڈل کرنے، پرانے API ورژن میں غائب فیلڈز کو سنبھالنے یا ایک سے زیادہ JSON کلیدوں کو ایک پراپرٹی میں یکجا کرنے کی اجازت دیتا ہے۔

struct Order: Decodable {
    let orderId: String
    let amount: Double
    let status: OrderStatus

    enum OrderStatus: String, Decodable {
        case pending, confirmed, shipped, cancelled
    }
}

let decoder = JSONDecoder()
decoder.dateDecodingStrategy = .iso8601
let order = try decoder.decode(Order.self, from: jsonData)

DateDecodingStrategy یہ طے کرتی ہے کہ JSONDecoder تاریخ کی سٹرنگز کی تشریح کیسے کرتا ہے۔ .iso8601 سب سے زیادہ استعمال ہوتا ہے — معیاری REST API فارمیٹ۔ نیسٹڈ enum OrderStatus خود بخود JSON سٹرنگ ویلیوز سے ڈی کوڈ ہوتا ہے۔ یہ مجک نمبروں سے بچاتا ہے اور کوڈ کو خود دستاویزی بناتا ہے — آرڈر کی حالت ہمیشہ سختی سے متعین اقدار کا ایک سیٹ رکھتی ہے۔

Codable میں Property Wrappers

Swift 4.2 سے، Codable انفرادی پراپرٹیز کی کسٹم ڈی سیریلیائزیشن کے لیے property wrappers کو سپورٹ کرتا ہے۔ @DefaultValue ایک مقبول wrapper ہے جو JSON میں فیلڈ کی غیر موجودگی میں ڈیفالٹ ویلیو سیٹ کرتا ہے۔ @LosslessString سٹرنگ کو نمبر میں اور اس کے برعکس تبدیل کرتا ہے۔ یہ خاص طور پر مفید ہے جب سرور id کو سٹرنگ "123" کے طور پر بھیجتا ہے لیکن ماڈل Int کی توقع رکھتا ہے۔ Property wrappers init(from:) میں بوائلر پلیٹ کوڈ کو کم کرتے ہیں اور ماڈلز کو صاف ستھرا بناتے ہیں۔

Android پر ڈی سیریلیائزیشن

Android پر، ڈی سیریلیائزیشن لائبریری کا انتخاب زبان اور پروجیکٹ کی ضروریات پر منحصر ہے۔ Google کا Gson سب سے عام آپشن ہے، جو reflection کے ذریعے کام کرتا ہے لیکن پیچیدہ درجہ بندی پر کارکردگی کے مسائل ہیں۔ Square کا Moshi reflection اور code generation دونوں کو سپورٹ کرتا ہے، کم میموری استعمال کرتا ہے اور بڑے جوابات کو تیزی سے پروسیس کرتا ہے۔ JetBrains کا kotlinx.serialization کمپائلر انٹیگریشن کے ساتھ ایک مقامی Kotlin حل ہے جو بالکل reflection استعمال نہیں کرتا۔

@Serializable
data class User(
    @SerialName("user_id")
    val userId: Int,
    val name: String,
    val email: String,
    @SerialName("created_at")
    val createdAt: String
)

val json = Json { ignoreUnknownKeys = true }
val user = json.decodeFromString<User>(response)

@Serializable ایک Kotlin کمپائلر اینوٹیشن ہے جو کلاس کے لیے کوڈ جنریشن کو فعال کرتا ہے۔ ignoreUnknownKeys پیرامیٹر کریش کو روکتا ہے اگر سرور ماڈل میں غائب فیلڈ بھیجتا ہے۔ snake_case کلیدوں کے میپنگ کے لیے @SerialName استعمال کیا جاتا ہے — iOS کے convertFromSnakeCase کے مساوی۔ JetBrains (2026) کے مطابق، لائبریری ملٹی پلیٹ فارم کو سپورٹ کرتی ہے: وہی Serializable کلاس Android، iOS (KMP) اور سرور سائڈ Kotlin پر کام کرتی ہے۔

Gson، Moshi اور kotlinx.serialization کا موازنہ

لائبریریوں کے درمیان انتخاب رفتار اور لچک کے درمیان سمجھوتے پر آتا ہے۔ Gson پروٹوٹائپس اور Java پروجیکٹس کے لیے اچھا ہے — اسے اینوٹیشنز کی ضرورت نہیں ہے اور یہ فوراً کام کرتا ہے۔ Moshi درمیانی پوزیشن رکھتا ہے: @JsonClass(generateAdapter = true) کے ذریعے codegen kotlinx.serialization کے قریب رفتار دیتا ہے، جبکہ reflection موڈ Gson کی لچک فراہم کرتا ہے۔ kotlinx.serialization خالص Kotlin پروجیکٹس کے لیے تیز ترین آپشن ہے لیکن اسے Kotlin 1.4+ اور Gradle میں Kotlin Serialization پلگ ان کی ضرورت ہے۔

عام غلطیاں اور ان کی روک تھام

Type mismatch ایک ایسی صورت حال ہے جہاں JSON میں ایک قسم کی قدر ہوتی ہے لیکن ماڈل دوسری قسم کی توقع رکھتا ہے۔ سرور نے نمبر کے بجائے سٹرنگ "42" بھیجی، یا boolean true کے بجائے نمبر 1 بھیجا۔ iOS پر، JSONDecoder ڈیفالٹ طور پر DecodingError.typeMismatch پھینکے گا؛ Android پر، Gson تبدیلی کی کوشش کرے گا، جبکہ Moshi اور kotlinx.serialization کو واضح اڈیپٹرز کی ضرورت ہے۔ حل مخصوص فیلڈز کے لیے lenient حکمت عملی یا کسٹم ڈی سیریلیائزر استعمال کرنا ہے۔

غائب فیلڈز اور Nullable

جب سرور ایک اختیاری فیلڈ شامل نہیں کرتا، تو کوڈ غلطی کے ساتھ کریش ہو جاتا ہے۔ Swift میں Optional فیلڈز اور Kotlin میں nullable اقسام مسئلہ حل کرتی ہیں: اگر فیلڈ null ہے یا JSON میں موجود نہیں ہے، تو پراپرٹی nil/null حاصل کرتی ہے اور ایپلیکیشن کام جاری رکھتی ہے۔ لازمی فیلڈز کے لیے، ڈی سیریلیائزیشن سے پہلے API کلائنٹ لیول پر ان کی موجودگی چیک کرنا مناسب ہے۔ Moshi اور kotlinx.serialization ڈیفالٹ طور پر تمام فیلڈز کی ضرورت ہوتی ہے — nullable مارکنگ اور ڈیفالٹ ویلیوز اس پابندی کو ہٹا دیتے ہیں۔

API ورژن کی عدم مطابقت

سرور پر JSON ساخت میں تبدیلی پروڈکشن کریش کا ایک عام ذریعہ ہے۔ معیاری عمل روٹ آبجیکٹ میں version فیلڈ کے ذریعے اسکیما ورژننگ اور کلائنٹ پر 2-3 پچھلے ورژنز کو سپورٹ کرنا ہے۔ kotlinx.serialization مختلف ورژنز کے لیے متعدد ماڈلز اعلان کرنے اور JsonElement میں ابتدائی پارسنگ کے بعد version فیلڈ کی بنیاد پر صحیح ماڈل منتخب کرنے کی اجازت دیتا ہے۔ اضافی تحفظ میں نئے فیلڈز کے لیے ignoreUnknownKeys اور ان فیلڈز کے لیے ڈیفالٹ ویلیوز شامل ہیں جنہیں ہٹایا جا سکتا ہے۔

ڈی سیریلیائزیشن کی غلطیوں کی لاگنگ پروڈکشن میں ایک لازمی عمل ہے۔ decode کو do/catch میں لپیٹیں، خام JSON اور متوقع ماڈل کی قسم کو Crashlytics یا Sentry میں لاگ کریں۔ اس سے فوری طور پر پتہ چل جائے گا کہ کس API کا کون سا فیلڈ کس ایپ ورژن پر ٹوٹا ہے۔ لاگنگ کے بغیر، ڈی سیریلیائزیشن کی غلطی بغیر سیاق و سباق کے ایک پراسرار کریش کی طرح دکھائی دیتی ہے۔