Door Bauke Schievink, donderdag 3 januari 2013 07:59, views: 22.903 •

De 'niet storen'-feature die in iOS 6 zit ingebakken zal na 7 januari weer als vanouds werken, zo heeft Apple beloofd. Na de jaarwisseling bleek dat de functionaliteit, die geluiden van binnenkomende notificaties uitzet, ook buiten de ingestelde tijd geluiden dempt.

Op de site van Apple is een verklaring gepubliceerd waarin het probleem met de 'niet storen'-feature wordt erkend. De fabrikant laat weten dat Do Not Disturb buiten de ingestelde tijd blijft werken, waardoor gebruikers geluiden voor binnenkomende notificaties van bijvoorbeeld telefoongesprekken of berichten missen. Volgens Apple zal de functie na 7 januari weer normaal werken. Tot die tijd wordt geadviseerd om handmatig 'niet storen' uit te zetten. Een verklaring voor de bug werd niet gegeven.

De problemen met 'niet storen' verschenen na de jaarwisseling, toen gebruikers op verscheidene fora en sociale media lieten weten dat de functionaliteit zichzelf niet automatisch uitschakelde. De functionaliteit werd door Apple geïntroduceerd in iOS 6 en kan er bijvoorbeeld voor zorgen dat gebruikers 's nachts niet gestoord worden door geluiden van binnenkomende notificaties.

Het is niet de eerste keer dat iOS-software met problemen kampt na een jaarwisseling. Twee jaar geleden gebeurde dat ook al, toen bleek dat ingestelde wekkers niet langer functioneerden. Ook toen liet Apple weten dat de functionaliteit zichzelf zou herstellen, maar toch bleef een aantal gebruikers nog last hebben van de bug.

Reacties (75)

Reactiefilter:-175074+150+22+30
Threaded weergave•Sorteer aflopend•Faq
«  1  2  3  4  »
0 KvanSteijn
3 januari 2013 08:04
Het is ook gewoon super lastig om met alles rekening mee te houden als het om tijd gaat. Wintertijd, zomertijd enzovoort!
+1 jongetje
@KvanSteijn • 3 januari 2013 08:07
Ik ken de functionaliteit niet, maar ik neem aan dat je gewoon per dag kun instellen hoelaat het an en uit moet. Wat maakt dan de zomertijd, uur tijdsverschil, schikkeljaar e.d. uit? Je kunt toch gewoon de tijd uitlezen, die is elke dag hetzelfde en als het moment passeert zetj e de functionaliteit aan of uit.

Ik heb het idee dat er veel code wordt geschreven die volledig zinloos is. Allemaal onnodige complexiteit. Hetzelfde als met die wekker bug, waarom zou je met alle mogelijke variabelen rekening houden als de wekker om 8uur moet afgaan. Kwestie van checken of het 8uur is, indien ja, wekker aflaten lopen (maar misschien ben ik te simpel :) )
+1 thalantis
3 januari 2013 08:10
DST (daylight saving time) is lastiger dan je denkt, kijk hier maar eens naar
http://www.youtube.com/watch?v=84aWtseb2-4

(reactie op KvanSteijn)

[Reactie gewijzigd door thalantis op 3 januari 2013 08:11]

+1 XiniX88
@jongetje • 3 januari 2013 08:11
De hardware moet uit de wake komen, hierdoor moet men van te voren aangeven over hoeveel uur je toestel moet ontwaken.

Als hierbij geen rekening wordt gehouden met zomer/winter tijd, wordt jou telefoon te vroeg of te laat ontwaakt en zal hij falen.

Tuurlijk kan je je device ook de hele tijd laten pollen
while(true)
if(wekkerTijd > huidigeTijd)
ga af

Maar dat lijkt mij niet de meest goedkope oplossing (batterij enzo, je mobiel blijft dan actief).
@Carino: Requires data connection
@Blokker_1999: Als iemand mij belt moet mijn telefoon ook uit de idle stand komen, dus nee, tuurlijk doet hij dingen op de achtergrond.

[Reactie gewijzigd door XiniX88 op 3 januari 2013 08:48]

+1 thekingofping
@KvanSteijn • 3 januari 2013 08:14
Maakt niet uit of het "super lastig is". Het moet gewoon werken. Wat heb ik aan een telefoon die niet overgaat als je gebeld wordt?

Als het te "super lastig is" moeten ze het niet vrijgeven. Aan halfwerkende functies hebben we niets.
+1 airell
@KvanSteijn • 3 januari 2013 08:20
(...) Wintertijd, zomertijd enzovoort!
Volgens mij ging de klok niet vooruit of achteruit rond oud en nieuw. Als de wekker nu 0x of 2x afgaat bij zomer (er is geen 2:30) of wintertijd (er is 2x 2:30), dan kan ik me nog enigsinds een 'lastige' uitdaging indenken...
+1 robertwebbe
3 januari 2013 08:20
Als je de datum handmatig wijzigt naar 7 januari zet is het inderdaad verholpen :)
0 Boy
@KvanSteijn • 3 januari 2013 08:24
LOL, dat zijn inderdaad wel de moeilijkste dingen bij software ontwikkeling :p
+1 ultimasnake
3 januari 2013 08:25
Vreemd 1 jan had ik hier last van maar sinds gister werkt het weer prima. Verder blijft het een raar verhaal. Wat maakt 2013 zo speciaal dat een tijdgebonde (niets met datum te maken) functie niet meer werkt??

Verder mij benieuwen of straks zomertijd of 2014 dan ook niet aan de orde zijn..

[Reactie gewijzigd door ultimasnake op 3 januari 2013 08:27]

0 Carino
@XiniX88 • 3 januari 2013 08:28
de meest eenvoudige oplossing hierin zal Apple's eigen Push notificatie systeem zijn... Enige wat je hoeft te doen is een nieuw bericht type in het leven te roepen die nooit zichtbaar zal worden maar wel applicaties (of enkel het toestel) even wakker kunnen maken... dan heb je verder geen enkele logica op de telefoon nodig.

probleem is dan echter wel dat een bericht gemist kan worden en dan krijg je selectief niet goed werkende software...
+2 inorde
@KvanSteijn • 3 januari 2013 08:28
Dat vind ik flauwekul.

Als programmeur wordt je verwacht 'superlastige' problemen op te lossen, anders had iedereen wel kunnen programmeren. Daarnaast heeft het niks te maken met zomer/wintertijd, gezien we midden in de wintertijd zitten. Ik ben overigens zelf ook programmeur.

Begrijp me niet verkeerd, de bug bij Google wat betreft de missende December van pasgeleden is net zo prutserig.

Zo'n dingen komen gewoon voor omdat er ontzettend veel druk ligt op het team om zoveel mogelijk features erin te bouwen, met harde release dates. Bugs zijn onvermijdelijk, maar dit zijn wel grote flaters als je het mij vraagt.

Dat gezegd hebbende: Apple's reactie is logisch, de bug gaat vanzelf weg. Dat lijkt lui, maar het is natuurlijk niet makkelijk of nuttig om voor die tijd nog een fix te releasen. Het duurt enkele dagen voordat je je code volledig getest hebt, dan nog eens enkele dagen voordat je de update kunt verspreiden.
+1 eL-Prova
3 januari 2013 08:29
Wel beetje makkelijke weg zeg. Ondanks dat er een work-around schijnbaar is lijk me toch allerminst dat je zulke problemen oplost. Ik zag al inderdaad dat een aantal hier de datum naar 7 januari verplaatst dat die het niet meer doet. Probleem kan ik ongeveer weg gokken...deze week is week 53/week 01, bij oa opvragen via PHP met date("Y") krijg je 2012 ipv 2013. Door gebruik te maken van unix tijd date("o") krijg je wel de correcte jaar. Liep er vorige week tegenaan :+

Terugkomend op de reactie van Apple, mijn klanten zouden het niet accepteren als ik zou zeggen, wacht maar even een weekje dan doet alles het weer...
+1 mr.maestro
@thalantis • 3 januari 2013 08:29
Geweldig interessante video. Nooit geweten dat dit zo versnipperd was... Wat mij betreft > afschaffen die handel.

Maar dit topic gaat over de jaarwisseling, en dat heeft natuurlijk niets te maken met de DST. Ook een jaarwisseling is lastig te testen, zeker onder een betatest groep die zomers bezig is, maar dit zou op zich eruit te halen moeten zijn. En het is opmerkelijk dat iOS telkens weer moeite heeft met dit soort tijddingetjes...
+1 Keypunchie
@ultimasnake • 3 januari 2013 08:34
Het zal iets met laatste/'1e week" van het jaar te maken hebben, die eigenlijk al de 2e week is.
+1 ikkuh61
@KvanSteijn • 3 januari 2013 08:39
Voor een super groot bedrijf met super veel resources denk ik dat dit probleem een eitje moet zijn. Dit geldt niet alleen voor Apple overigens.
+1 Blokker_1999
@XiniX88 • 3 januari 2013 08:40
Je denkt nu toch niet dat wanneer je telefoon in standby staat dat deze helemaal geen dataverwerking meer doet mag ik hopen. De CPU blijft gewoon op laag tempo werken en de achtergrondprocessen blijven netjes hun ding doen. De applicatie moet gewoon op bepaalde intervallen kijken of er actie ondernomen moet worden en als de tijd gekomen is alles doen om die actie ook te laten uitvoeren. Er moet helemaal van te voren niet gekeken worden hoe lang het nog moet duren.
0 alexbl69
@mr.maestro • 3 januari 2013 08:48
Idd: zal wel zwaar OT zijn maar dat hele zomer- / wintertijdgedoe is zo enorm achterhaald.

Toen de meerderheid der mensheid nog van 8 tot 5 actief was, was hier wellicht een energiebesparing te behalen. Maar aangezien we tegenwoordig van 6 uur 's ochtends tot 10 uur 's avonds actief zijn, is dit volstrekt nutteloos geworden.

Kijk nu naar deze tijd. Het is nu nog praktisch donker buiten (kwart voor 9). Als ik vanavond naar huis ga om 5 uur is het ook alweer donker. Wat is dan de besparing? Niks toch 8)7 ?

Het omzetten van die klokken (waar zoals het filmpje bewijst ook geen enkele standaard voor is), is enkel tijdrovend, irritant en kost ons alleen maar geld (verloren tijd door instellen, vergissingen en de - weer ontopic - onvermijdelijke bugs in allerlei software).
+1 jfversluis
@eL-Prova • 3 januari 2013 08:54
Maar zo te zien is jouw bug server-side op te lossen en heeft dat geen betrekking op een fix verspreiden over miljoenen devices. Een proces dat waarschijnlijk net zo lang duurt als gewoon 4 dagen uitzitten.

Begrijp me niet verkeerd, het is slordig. Maar geef toe; is het nou écht zo'n kritieke feature?

Daarbij kan een gevestigd multinational als Apple deze 'arrogante' houding gewoon aannemen natuurlijk, daar ze genoeg in reserve hebben en ze dit waarschijnlijk niet eens een cent zal schelen.

[Reactie gewijzigd door jfversluis op 3 januari 2013 08:58]

+1 Carino
@Blokker_1999 • 3 januari 2013 09:00
het bereik kan soms toch weg vallen... dan kan je nog zo'n goede data verbinding hebben, push wordt dan gewoon niet ontvangen.

uiteraard kan het allemaal netjes met achtergrondprocessen etc, maar het zal me niks verbazen als ze voor een centraal beheerde oplossing gekozen hebben...
+1 Patrijz
@eL-Prova • 3 januari 2013 09:03
Het punt is dat niet 'alles' stuk is, maar een functie waar mensen prima zonder mee kunnen. Neemt niet weg dat het erg slordig is, en natuurlijk niet had mogen gebeuren. Maar goed, dates en programmatuur zijn altijd een apart verhaal, zou inderdaad goed te maken kunnen hebben met week 1.

Op dit item kan niet meer gereageerd worden.

«  1  2  3  4  »

Onderwerpen

Gerelateerde content