So far,
we've used the loadContainerPreferFresh method to load the container.
And this takes the containerID,
which you get from the TagManager UI, and the defaultContainer.
So this method checks if the app has a container
that's been refreshed in the past 12 hours or so.
And if it does, then we load the container.
And if there isn't a fresh container, then load a new one over the network.
And if there's a timeout or a network error before the container
finishes loading, then the container holder status is set to unsuccessful.
There are a couple of other methods for loading the container,
loadContainerDefaultOnly, which will only get the default container,
and then there's also loadContainerPreferNonDefault.
So this one prefers to not use the default container but
doesn't necessarily look for a fresh container.
To get the freshest value, use loadContainerPreferFresh.
But fresh is a relative term.
If we look at the reference page for TagManager, it says that the mobile app
refreshes a container from the network every 12 hours.
So one of the benefits of TagManager is that non-developers
cannot put changes to an app.
And these will often be bulk uploads of many values.
This mechanism is not really meant for second-by-second changes, but
it's nice to see the changes when we're developing our app.
And that's why we added the call to manually refresh the container.
Here's the reference, the refresh method on the container.
And it says, in order to limit the frequency of network communication,
refresh method is throttled, and that you're supposed to wait at least 15
minutes before calling this method again.
So even manual refreshes are not guaranteed to take effect
more than about every 15 minutes.
I've had good luck with my changes taking effect very quickly
when I change variable values in TagManager, but it's not guaranteed.
If you don't see the changes taking effect immediately,
don't be too surprised.
وحتى الآن،
استخدمنا طريقة loadContainerPreferFresh لتحميل الحاوية
وهذا يتطلب معرف الحاوية،
الذي تحصل عليه من واجهة مستخدم TagManager، وdefaultContainer.
لذا تتحقق هذه الطريقة إذا كان التطبيق يحتوي على حاوية
تم تحديثها في مدة 12 ساعة الماضية تقريبًا.
وإذا كان الأمر كذلك، فعندئذٍ نُحمّل الحاوية.
وإذا لم تتواجد حاوية محدّثة، فعندئذٍ حمّل أخرى جديدة على الشبكة.
وإذا أتيحت فترة زمنية أو كان هناك خطأ في الشبكة قبل الانتهاء من
تحميل الحاوية، فعندئذٍ يتم تعيين حالة صاحب الحاوية على غير ناجحة.
توجد مجموعة من الطرق الأخرى لتحميل الحاوية،
loadContainerDefaultOnly، التي تحصل فقط على الحاوية الافتراضية،
وتوجد أيضًا loadContainerPreferNonDefault.
لذلك تفضل هذه الطريقة عدم استخدام الحاوية الافتراضية لكن
من غير الضروي البحث عن حاوية محدّثة.
للحصول على أحدث قيمة، استخدم loadContainerPreferFresh.
لكن التحديث هو مصطلح نسبي.
إذا ألقينا نظرة على صفحة المرجع لـ TagManager، فيمكن القول أن التطبيق المحمول
يحدّث الحاولة من الشبكة كل 12 ساعة.
لذلك أحد مزايا TagManager هي عدم تمكن غير المطورين من
إجراء تغييرات على التطبيق.
وغالبًا ما تكون هذه جملة من التحميلات الخاصة بالعديد من القيم.
لا يقصد من هذه الآلية في الواقع التغييرات التي تتم ثانية بثانية، لكن
من الجيد رؤية التغييرات عندما نطور التطبيق الخاص بنا.
ولهذا السبب قمنا بإضافة الاستدعاء لتجديد الحاوية يدويًا.
وإليك المرجع، طريقة التحديث على الحاوية.
ويمكن القول، من أجل الحد من تكرار الاتصال بالشبكة
وتقييد طريقة التجديد وأن من المفروض الانتظار 15 دقيقة
على أقل تقدير قبل استدعاء هذه الطريقة مرة أخرى.
وبالتالي حنى التجديدات اليدوية غير مضمون أن تؤثر
لأكثر من 15 دقيقة.
من حسن حظي أن التغييرات التي اجريتها تحدث بسرعة جدًا
عند تغيير القيم المتغيرة في TagManager، لكن ذلك غير مضمون.
إذا لم تُحدث التغييرات تأثيرًا على الفور،
فلا تندهش.
Até aqui, usamos o método loadContainerPreferFresh
para carregar o contêiner.
Isso pega o containerID,
que você obtém na IU do TagManager,
e o defaultContainer.
Esse método verifica se o aplicativo tem um contêiner
que foi atualizado nas última 12 horas.
E se tiver, então, carregamos o contêiner.
E caso não haja um contêiner atualizado,
carregue um novo na rede.
E em caso de tempo limite ou erro de rede
antes do contêiner finalizar o carregamento,
então, o status do ContainerHolder
é definido como falha.
Há alguns outros métodos para carregar o contêiner:
loadContainerDefaultOnly,
que obtém somente o contêiner padrão,
e também o loadContainerPreferNonDefault.
Este prefere não usar o contêiner padrão,
mas não necessariamente procura um contêiner atualizado.
Para obter o valor mais atualizado, use loadContainerPreferFresh.
Mas atualizado é um termo relativo.
Se consultarmos a página de referência do TagManager,
ela diz que o aplicativo móvel
atualiza um contêiner a partir da rede a cada 12 horas.
Um dos benefícios do TagManager
é que não desenvolvedores não podem fazer alterações no aplicativo.
Geralmente, tratam-se de atualizações em massa de vários valores.
Esse mecanismos não é ideal para alterações a cada segundo,
mas é bom ver as alterações durante o desenvolvimento do aplicativo.
E é por isso que adicionamos a chamada para atualizar manualmente o contêiner.
Aqui está a referência, do método refresh no contêiner.
E ela diz: "para limitar a frequência
da comunicação de rede,
o método refresh é limitado".
E diz que você deve "esperar, no mínimo, 15 minutos
antes de chamar esse método novamente".
Então, nem nas atualizações manuais há a garantia de que elas farão efeito
mais rapidamente do que a cada 15 minutos.
Por sorte, minha alterações estão sendo efetivadas rapidamente
quando mudo os valores variáveis no TagManager,
mas isso não é algo garantido.
Caso as alterações não ocorram imediatamente,
não se surpreenda.
到现在为止，
我们已经使用 loadContainerPreferFresh 方法来装载容器。
该方法使用 containerID
与 defaultContainer，前者 可以从 TagManager UI 中获得。
这种方法会检查 应用是否拥有
在过去大约 12 小时内 更新的容器。
如果有，我们 就加载该容器。
如果没有新容器， 我们就通过网络加载新容器。
如果在容器加载完成之前 出现超时或网络错误，
会将容器所有者状态 设置为不成功。
还有其他两种方法 可以加载容器，
一种是 loadContainerDefaultOnly， 该方法只能获得默认容器，
另一种是 loadContainerPreferNonDefault。
这种方法倾向于 不使用默认容器，也不必
寻找 新容器。
要获得最新的值，请使用 loadContainerPreferFresh。
不过“新”是相对的说法。
如果您查看 TagManager 的参考页， 会发现上面说移动应用从网络
每 12 小时 更新一次容器。
使用 TagManager 的好处之一， 就是非开发人员无法
更改应用。
这些更新通常 会上载大量的值。
对于每秒都会进行的更改而言， 这种机制没有实在意义，
不过我们在开发应用时， 看到更改是件不错的事情。
因此，我们添加了调用， 以便手动更新容器。
这是参考，以及 容器的更新方法。
这些文本表明，为了限制 网络通信的频率，
对更新方法进行了限制，并让您 等待至少 15 分钟后
才能再次 调用此方法。
因此，即使是手动更新， 生效时间也不能保证
超过 15 分钟。
我的运气不错， 在 TagManager 中
更改变量值后，更改很快生效， 但我不能保证每次都能这样。
如果您没能看到 更改立即生效，
请别太惊讶。